<?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.26 (Ruby 2.6.10) --> version='1.0' encoding='UTF-8'?>

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

<?rfc docmapping="yes"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-irtf-coinrg-use-cases-07" number="9817" category="info" consensus="true" updates="" obsoletes="" submissionType="IRTF" tocInclude="true" sortRefs="true" symRefs="true" tocDepth="2"> tocDepth="2" version="3" xml:lang="en">

  <front>
    <title abbrev="COIN Use Cases">Use Cases for In-Network Computing</title>
    <seriesInfo name="RFC" value="9817"/>
    <author initials="I." surname="Kunze" fullname="Ike Kunze">
      <organization abbrev="RWTH Aachen">RWTH Aachen University</organization>
      <address>
        <postal>
          <street>Ahornstr. 55</street>
          <city>Aachen</city>
          <code>D-52074</code>
          <country>Germany</country>
        </postal>
        <email>kunze@comsys.rwth-aachen.de</email>
      </address>
    </author>
    <author initials="K." surname="Wehrle" fullname="Klaus Wehrle">
      <organization abbrev="RWTH Aachen">RWTH Aachen University</organization>
      <address>
        <postal>
          <street>Ahornstr. 55</street>
          <city>Aachen</city>
          <code>D-52074</code>
          <country>Germany</country>
        </postal>
        <email>wehrle@comsys.rwth-aachen.de</email>
      </address>
    </author>
    <author initials="D." surname="Trossen" fullname="Dirk Trossen">
      <organization abbrev="Huawei">Huawei Technologies Duesseldorf GmbH</organization>
      <address>
        <postal>
          <street>Riesstr. 25C</street>
          <city>Munich</city>
          <code>D-80992</code>
          <country>Germany</country>
        </postal>
        <email>Dirk.Trossen@Huawei.com</email>
      </address>
    </author>
    <author initials="M. J." initials="M-J." surname="Montpetit" fullname="Marie-Jose Montpetit">
      <organization abbrev="McGill">McGill University</organization>
      <address>
        <postal>
          <street>680 Sherbrooke Street W.</street>
          <city>Montreal</city>
          <code>H3A 3R1</code>
          <country>Canada</country>
        </postal>
        <email>marie-jose.montpetit@mcgill.ca</email>
      </address>
    </author>
    <author initials="X." surname="de Foy" fullname="Xavier de Foy">
      <organization>InterDigital Communications, LLC</organization>
      <address>
        <postal>
          <street>1000 Sherbrooke West</street>
          <city>Montreal</city>
          <code>H3A 3G4</code>
          <country>Canada</country>
        </postal>
        <email>xavier.defoy@interdigital.com</email>
      </address>
    </author>
    <author initials="D." surname="Griffin" fullname="David Griffin">
      <organization abbrev="UCL">University College London</organization>
      <address>
        <postal>
          <street>Gower St</street>
          <city>London</city>
          <code>WC1E 6BT</code>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>d.griffin@ucl.ac.uk</email>
      </address>
    </author>
    <author initials="M." surname="Rio" fullname="Miguel Rio">
      <organization abbrev="UCL">University College London</organization>
      <address>
        <postal>
          <street>Gower St</street>
          <city>London</city>
          <code>WC1E 6BT</code>
          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>miguel.rio@ucl.ac.uk</email>
      </address>
    </author>
    <date />

    <area>General</area>
    <workgroup>COINRG</workgroup> year="2025" month="July"/>

    <workgroup>Computing in the Network (COIN)</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>

<!-- [rfced] Please ensure that the guidelines listed in Section 2.1 of
RFC 5743 have been adhered to in this document. See
https://www.rfc-editor.org/rfc/rfc5743.html#section-2.1.
-->

    <abstract>
      <t>Computing in the Network (COIN) comes with the prospect of deploying
      processing functionality on networking devices, devices such as switches and
      network interface cards.  While such functionality can be beneficial, it
      has to be carefully placed into the context of the general Internet communication
      communication, and it needs to be clearly identified where and how those
      benefits apply.</t>
      <t>This document presents some use cases to demonstrate how a number of
      salient COIN-related applications can benefit from COIN.  Furthermore,
      to guide research on COIN, it identifies essential research questions
      and outlines desirable capabilities that COIN systems addressing the these use
      cases may need to support.  Finally, the document provides a preliminary
      categorization of the described research questions to source future work
      in this domain.
It  This document is a product of the Computing in the Network
      Research Group (COINRG).  It is not an IETF product and it is not a
      standard.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro"><name>Introduction</name> anchor="intro">
      <name>Introduction</name>
      <t>The Internet was designed as a best-effort packet network, forwarding
      packets from source to destination with limited guarantees regarding
      their timely and successful reception.  Data manipulation, computation,
      and more complex protocol functionality is functionalities are generally provided by the end-hosts
      end hosts, while network nodes are traditionally kept simple and only
      offer a "store and forward" packet facility.  This simplicity of purpose
      of the network has shown to be suitable for a wide variety of
      applications and has facilitated the rapid growth of the Internet while Internet.  However,
      introducing middleboxes with specialized functionality for enhancing
      performance has often led to problems due to their inflexibility.</t>
      <t>However, with the rise of new services, some of which are described
      in this document, there is a growing number of application domains that
      require more than best-effort forwarding forwarding, including strict performance
      guarantees or closed-loop integration to manage data flows.  In this
      context, allowing for a tighter integration of computing and networking
      resources for enabling a more flexible distribution of computation tasks
      across the network, e.g., network (e.g., beyond 'just' "just" endpoints and without requiring
      specialized middleboxes, middleboxes) may help to achieve the desired guarantees and
      behaviors, increase overall performance, and improve resilience to
      failures.</t>
      <t>The vision of 'in-network computing' "in-network computing" and the provisioning of such
      capabilities that capitalize on joint computation and communication
      resource usage throughout the network is part of the move from a
      telephone network analogy of the Internet into a more distributed
      computer board architecture.  We refer to those capabilities as 'COIN capabilities' "COIN
      capabilities" in the remainder of the document.</t>
      <t>We believe that this vision of 'in-network computing' in-network computing can be best
      outlined along four dimensions of use cases, namely those that (i) provide that:</t>
      <ol type="i">
	<li>provide new user experiences through the utilization of COIN
	capabilities (referred to as 'COIN experiences'), (ii) enable "COIN experiences"),</li>
	<li>enable new COIN systems, e.g., systems (e.g., through new interactions
	between communication and compute providers, (iii) improve providers),</li>
	<li>improve on already existing COIN capabilities, and (iv) enable and</li>
	<li>enable new COIN capabilities.
Sections 3 capabilities.</li>
      </ol>
      <t>Sections <xref target="newExperiences" format="counter"/> through 6 <xref
      target="newCapabilities" format="counter"/> capture those categories of
      use cases and provide the main structure of this document.  The goal is
      to present how computing resources inside the network impact existing
      services and applications or allow for innovation in emerging
      application domains.</t>
      <t>By delving into some individual examples within each of the above
      categories, we outline opportunities and propose possible research
      questions for consideration by the wider community when pushing forward 'in-network computing'
      in-network computing architectures.  Furthermore, identifying
      desirable capabilities for an evolving solution space of COIN systems is
      another objective of the use case descriptions. To achieve this, the
      following taxonomy is proposed to describe each of the use cases:</t>

<t><list style="numbers">
  <t>Description: High-level

     <dl spacing="normal" newline="false">
       <dt>Description:</dt><dd>A high-level presentation of the purpose of the
       use case and a short explanation of the use case behavior.</t>
  <t>Characterization: Explanation behavior.</dd>
       <dt>Characterization:</dt><dd>An explanation of the services that are
       being utilized and realized as well as the semantics of interactions in
       the use case.</t>
  <t>Existing solutions: Description case.</dd>
       <dt>Existing Solutions:</dt><dd>A description of current methods that may
       realize the use case (if they exist), though not claiming to exhaustively
       review the landscape of solutions.</t>
  <t>Opportunities: An solutions.</dd>
       <dt>Opportunities:</dt><dd>An outline of how COIN capabilities may
       support or improve on the use case in terms of performance and other metrics.</t>
  <t>Research questions: Essential
       metrics.</dd>
       <dt>Research questions:</dt><dd>Essential questions that are suitable
       for guiding research to achieve the identified opportunities. The
       research questions also capture immediate capabilities for any COIN
       solution addressing the particular use case whose development may
       immediately follow when working toward answers to the research questions.</t>
  <t>Additional
       questions.</dd>
       <dt>Additional desirable capabilities: Description capabilities:</dt><dd>A description of
       additional capabilities that might not require research but may be
       desirable for any COIN solution addressing the particular use case; we
       limit these capabilities to those directly affecting COIN, recognizing
       that any use case will realistically require many additional
       capabilities for its realization. We omit this dedicated section if
       relevant capabilities are already sufficiently covered by the
       corresponding research questions.</t>
</list></t> questions.</dd>
     </dl>

      <t>This document discusses these six aspects along a number of
      individual use cases to demonstrate the diversity of COIN applications.
      It is intended as a basis for further analyses and discussions within
      the wider research community.  This document represents the consensus of
      COINRG.</t>
    </section>

    <section anchor="terms"><name>Terminology</name> anchor="terms">
      <name>Terminology</name>
      <t>This document uses the terminology defined below.</t>

<t>Programmable

      <dl spacing="normal" newline="false">

	<dt>Programmable Network Devices (PNDs): network (PNDs):</dt><dd>network devices, such
	as network interface cards and switches, which are programmable, e.g., programmable (e.g.,
	using P4 <xref target="P4"/> or other languages.</t>

<t>(COIN) Execution Environment: a languages).</dd>

	<dt>(COIN) execution environment:</dt><dd>a class of target
	environments for function execution, for example, a JVM-based an
	execution environment based on the Java Virtual Machine (JVM) that can run functions represented in JVM byte code</t>

<t>COIN System: the
	code.</dd>

	<dt>COIN system:</dt><dd>the PNDs (and end systems) and their
	execution environments, together with the communication resources
	interconnecting them, operated by a single provider or through
	interactions between multiple providers that jointly offer COIN capabilities</t>

<t>COIN Capability: a
	capabilities.</dd>

	<dt>COIN capability:</dt><dd>a feature enabled through the joint
	processing of computation and communication resources in the network</t>

<t>(COIN) Program: a
	network.</dd>

	<dt>(COIN) program:</dt><dd>a monolithic functionality that is
	provided according to the specification for said program and which may
	be requested by a user.  A composite service can be built by
	orchestrating a combination of monolithic COIN programs.</t>

<t>(COIN) Program Instance: one programs.</dd>

	<dt>(COIN) program instance:</dt><dd>one running instance of a program</t>

<t>COIN Experience: a program.</dd>

	<dt>COIN experience:</dt><dd>a new user experience brought about
	through the utilization of COIN capabilities</t> capabilities.</dd>

      </dl>
    </section>
    <section anchor="newExperiences"><name>Providing anchor="newExperiences">
      <name>Providing New COIN Experiences</name>
      <section anchor="mobileAppOffload"><name>Mobile anchor="mobileAppOffload">
        <name>Mobile Application Offloading</name>
        <section anchor="description"><name>Description</name> anchor="description">
          <name>Description</name>
          <t>This scenario can be exemplified in an immersive gaming
          application, where a single user plays a game using a Virtual
          Reality (VR) headset. <br /> The headset hosts several (COIN) programs.
          For instance, the "display" display (COIN) program renders frames to the
          user, while other programs are realized for VR content processing
          and to incorporate input data received from sensors, e.g., sensors (e.g., in bodily
          worn devices including the VR headset.</t>

<t>Once headset).</t>

<!-- [rfced] May we make this into two sentences as follows for ease of
the reader? Also, would you like to change the adjective "compute intensive"
to "CPU-intensive", which is used later in this document?

Original:
   Once this application is partitioned into its constituent (COIN)
   programs and deployed throughout a COIN system, utilizing a COIN
   execution environment, only the "display" (COIN) program may be left
   in the headset, while the compute intensive real-time VR content
   processing (COIN) program can be offloaded to a nearby resource rich
   home PC or a programmable network device (PND) in the operator's
   access network, for a better execution (faster and possibly higher
   resolution generation).

Perhaps:
   Once this application is partitioned into its constituent (COIN)
   programs and deployed throughout a COIN system utilizing a COIN
   execution environment, only the display (COIN) program may be left in
   the headset. Meanwhile, the CPU-intensive real-time VR content
   processing (COIN) program can be offloaded to a nearby resource rich
   home PC or a Programmable Network Device (PND) in the operator's
   access network for a better execution (i.e., faster and possibly higher
   resolution generation).
-->

          <t>Once this application is partitioned into its constituent (COIN)
          programs and deployed throughout a COIN system, utilizing a COIN
          execution environment, only the display (COIN) program may be left
          in the headset, while the compute intensive real-time VR content
          processing (COIN) program can be offloaded to a nearby resource rich
          home PC or a Programmable Network Device (PND) in the operator's
          access network, for a better execution (faster and possibly higher
          resolution generation).</t>
        </section>
        <section anchor="characterization"><name>Characterization</name> anchor="characterization">
          <name>Characterization</name>
          <t>Partitioning a mobile application into several constituent (COIN)
          programs allows for denoting the application as a collection of
          (COIN) programs for a flexible composition and a distributed
          execution.  In our example above, most capabilities of a mobile
          application can be categorized into any of three, "receiving", "processing", three groups: receiving,
          processing, and "displaying" groups.</t> displaying.</t>
          <t>Any device may realize one or more of the (COIN) programs of a
          mobile application and expose them to the (COIN) system and its
          constituent (COIN) execution environments.  When the (COIN) program
          sequence is executed on a single device, the outcome is what you
          traditionally see with applications running on mobile devices.</t>

<!-- [rfced] How may we update the following text to clarify the
relationship between the "result" and the phrases that follow?

Original:
   The result is the equivalent to 'mobile function offloading', for possible
   reduction of power consumption (e.g., offloading CPU intensive process
   functions to a remote server) or for improved end user experience (e.g.,
   moving display functions to a nearby smart TV) by selecting more suitably
   placed (COIN) program instances in the overall (COIN) system.

Option A:
   The result is the equivalent to mobile function offloading, in that it
   offers the possible reduction of power consumption (e.g., offloading CPU-
   intensive process functions to a remote server) or offers an improved
   end-user experience (e.g., moving display functions to a nearby smart TV)
   by selecting more suitably placed (COIN) program instances in the overall
   (COIN) system.

Option B (if *both* reducing power consumption and improving the end-user
experience are due to selecting more suitably placed program instances):

   The result is the equivalent to mobile function offloading because, by
   selecting more suitably placed (COIN) program instances in the overall
   (COIN) system, it offers a potential reduction of power consumption (e.g.,
   offloading CPU-intensive process functions to a remote server) or an
   improved end-user experience (e.g., moving display functions to a nearby
   smart TV).
-->
          <t>However, the execution of a (COIN) program may be moved to other
          (e.g., more suitable) devices, including PNDs, which have exposed
          the corresponding (COIN) program as individual (COIN) program
          instances to the (COIN) system by means of a 'service identifier'. service identifier.
          The result is the equivalent to 'mobile mobile function offloading', offloading, for
          possible reduction of power consumption (e.g., offloading CPU intensive CPU-intensive process functions to a remote server) or for improved end user
          end-user experience (e.g., moving display functions to a nearby
          smart TV) by selecting more suitably placed (COIN) program instances
          in the overall (COIN) system.</t>
          <t>We can already see a trend toward supporting such functionality with, e.g.,
          with relyiccng on dedicated cloud hardware (e.g., gaming platforms
          rendering content externally, relying on dedicated cloud hardware. externally). We envision, however, that such
          functionality is becoming more pervasive through specific
          facilities, such as entertainment parks or even hotels, in order to
          deploy needed edge computing capability capabilities to enable localized gaming
          as well as non-gaming scenarios.</t>

          <t><xref target="figureAppOffload"/> shows one realization
          of the above scenario, where a 'DPR app' "DPR app" is running on a mobile
          device (containing the partitioned Display(D), Process(P) and Receive(R) COIN programs) programs Display (D), Process (P) and
          Receive (R)) over a programmable switching, switching network, e.g., here an SDN, network. a Software-Defined Network (SDN) here.  The packaged applications are made available
          through a localized 'playstore server'. "playstore server".  The mobile application
          installation is realized as a 'service deployment' service deployment process, combining
          the local app installation with a distributed deployment (and
          orchestration) of one or more (COIN) programs on most suitable end
          systems or PNDs ('processing server').</t> (here, a "processing server").</t>

          <figure title="Application anchor="figureAppOffload">
            <name>Application Function Offloading Example." anchor="figureAppOffload"><artwork><![CDATA[ Example</name>
            <artwork><![CDATA[
                             +----------+ Processing Server
           Mobile            | +------+ |
        +---------+          | |  P   | |
        |   App   |          | +------+ |
        | +-----+ |          | +------+ |
        | |D|P|R| |          | |  SR  | |
        | +-----+ |          | +------+ |         Internet
        | +-----+ |          +----------+            /
        | |  SR | |              |                  /
        | +-----+ |            +----------+     +------+
        +---------+           /|SDN Switch|_____|Border|
                  +-------+ /  +----------+     |  SR  |
                  | 5GAN  |/        |           +------+
                  +-------+         |
      +---------+                   |
      |+-------+|               +----------+
      ||Display||              /|SDN Switch|
      |+-------+|   +-------+ / +----------+
      |+-------+|  /|WIFI AP|/
      ||   D   || / +-------+     +--+
      |+-------+|/                |SR|
      |+-------+|                /+--+
      ||  SR   ||            +---------+
      |+-------+|            |Playstore|
      +---------+            | Server  |
          TV                 +---------+

]]></artwork></figure>
]]></artwork>
          </figure>

          <t>Such localized deployment could, for instance, be provided by a
          visiting site, such as a hotel or a theme park.  Once the 'processing'
          processing (COIN) program is terminated on the mobile device, the 'service routing' (SR)
          "service routing (SR)" elements in the network route (service)
          requests instead to the (previously deployed) 'processing' processing (COIN)
          program running on the processing server over an existing SDN
          network.  Here, capabilities and other constraints for selecting the
          appropriate (COIN) program, in case of having deployed more than
          one, may be provided both in the advertisement of the (COIN) program
          and the service request itself.</t>
          <t>As an extension to the above scenarios, we can also envision that
          content from one processing (COIN) program may be distributed to
          more than one display (COIN) program, e.g., program (e.g., for multi/many-viewing scenarios. multi- and many-viewing
          scenarios).  Here, an offloaded "processing" processing program may collate
          input from several users in the (virtual) environment to generate a
          possibly three-dimensional render that is then distributed via a
          service-level multicast capability towards more than one "display" display
          (COIN) program.</t>
        </section>

        <section anchor="existing-solutions"><name>Existing anchor="existing-solutions">
          <name>Existing Solutions</name>

<!-- [rfced] We note that the reference [ETSI] uses "Multi-access Edge
Computing (MEC)" rather than "Mobile Edge Computing (MEC)" as seen in the
text below. May we update this sentence accordingly?

Original:
   The ETSI Mobile Edge Computing (MEC) [ETSI] suite of technologies
   provides solutions...

Perhaps:
  The ETSI Multi-access Edge Computing (MEC) [ETSI] suite of technologies
  provides solutions...
-->
          <t>The ETSI Mobile Edge Computing (MEC) <xref target="ETSI"/> suite
          of technologies provides solutions for mobile function offloading by
          allowing mobile applications to select resources in edge devices to
          execute functions instead of the mobile device directly.  For this,
          ETSI MEC utilizes a set of interfaces for the selection of suitable
          edge resources, connecting to so-called MEC application servers,
          while also allowing for sending data for function execution to the
          application server.</t>

<!-- [rfced] Please clarify this sentence, especially "rather than".

Original:
   Also, the ETSI work does not allow for the
   dynamic selection and redirection of (COIN) program calls to varying
   edge resources rather than a single MEC application server.

Option A:
   Also, the ETSI work does not allow for the
   dynamic selection and redirection of (COIN) program calls to varying
   edge resources; it does allow for them to a single MEC application server.

Option B (stating the reverse):
   Also, the ETSI work allows for the dynamic selection and
   redirection of (COIN) program calls to only a single MEC application
   server, not to varying edge resources.
-->

          <t>However, the technologies do not utilize micro-services microservices <xref target="Microservices"/> but
          target="Microservices"/>; they mainly rely on virtualization
          approaches such as containers or virtual machines, thus requiring a
          heavier processing and memory footprint in a COIN execution
          environment and the executing intermediaries.  Also, the ETSI work
          does not allow for the dynamic selection and redirection of (COIN)
          program calls to varying edge resources rather than a single MEC
          application server.</t>
          <t>Also, the selection of the edge resource (the app server) is
          relatively static, relying on DNS-based endpoint selection, which
          does not cater to the requirements of the example provided above,
          where the latency for redirecting to another device lies within a few
          milliseconds for aligning with the framerate frame rate of the display micro-service.</t>
          microservice.</t>
          <t>Lastly, MEC application servers are usually considered resources
          provided by the network operator through its MEC infrastructure,
          while our use case here also foresees the placement and execution of micro-services
          microservices in end user end-user devices.</t>
          <t>There also exists a plethora of mobile offloading platforms
          provided through proprietary platforms, all of which follow a
          similar approach as ETSI MEC in that a selected edge application
          server is being utilized to send functional descriptions and data
          for execution.</t>

<t>The draft at <xref target="APPCENTRES"/>
          <t><xref target="I-D.sarathchandra-coin-appcentres"/> outlines a
          number of enabling technologies for the use case, some of which have
          been realized in an Android-based realization of the micro-services microservices
          as a single application, which is capable to of dynamically redirect redirecting
          traffic to other micro-service microservice instances in the network.  This
          capability, together with the underlying path-based forwarding
          capability (using SDN) SDN), was demonstrated publicly, e.g., publicly (e.g., at the
          Mobile World Congress 2018 and 2019.</t> 2019).</t>
        </section>

        <section anchor="opportunities"><name>Opportunities</name>

<t><list style="symbols"> anchor="opportunities">
          <name>Opportunities</name>
          <ul spacing="normal">
            <li>
              <t>The packaging of (COIN) programs into existing mobile
              application packaging may enable the migration from current
              (mobile) device-centric execution of those mobile applications
              toward a possible distributed execution of the constituent
              (COIN) programs that are part of the overall mobile
              application.</t>
            </li>
            <li>
              <t>The orchestration for deploying (COIN) program instances in
              specific end systems and PNDs alike may open up the possibility
              for localized infrastructure owners, such as hotels or venue
              owners, to offer their compute capabilities to their visitors
              for improved or even site-specific experiences.</t>
            </li>
            <li>
              <t>The execution of (current mobile) app-level (COIN) programs
              may speed up the execution of said (COIN) program by relocating
              the execution to more suitable devices, including PNDs that may
              reside better located in relation to other (COIN) programs and
              thus improve performance, such as latency.</t>
  <t>The
            </li>

<!-- [rfced] Seems a closing parenthesis was missing on "(service routing
in [APPCENTRES]...". We added it; please review.

Original:
   *  The support for service-level routing of requests (service routing
      in <xref target="APPCENTRES"/> [APPCENTRES] may support higher flexibility when switching from
      one (COIN) program instance to another, e.g., due to changing
      constraints for selecting the new (COIN) program instance.  Here,
      PNDs may support service routing solutions by acting as routing
      overlay nodes to implement the necessary additional lookup
      functionality and also possibly support the handling of affinity
      relations, i.e., the forwarding of one packet to the destination
      of a previous one due to a higher level service relation, as
      discussed and described in [SarNet2021].

Current:
   *  The support for service-level routing of requests (such as service
      routing in [APPCENTRES]) may support higher flexibility when switching
      from one (COIN) program instance to another (e.g., due to changing
      constraints for selecting the new (COIN) program instance).  Here, PNDs
      may support service routing solutions by acting as routing overlay nodes
      to implement the necessary additional lookup functionality and also
      possibly support the handling of affinity relations (i.e., the
      forwarding of one packet to the destination of a previous one due to a
      higher level service relation as discussed and described in
      [SarNet2021]).
-->

            <li>
              <t>The support for service-level routing of requests (such as service
              routing in <xref target="SarNet2021"/>.</t> target="I-D.sarathchandra-coin-appcentres"/>)
              may support higher flexibility when switching from one (COIN)
              program instance to another (e.g., due to changing constraints
              for selecting the new (COIN) program instance).  Here, PNDs may
              support service routing solutions by acting as routing overlay
              nodes to implement the necessary additional lookup functionality
              and also possibly support the handling of affinity relations
              (i.e., the forwarding of one packet to the destination of a
              previous one due to a higher level service relation as
              discussed and described in <xref target="SarNet2021"/>).</t>
            </li>
            <li>
              <t>The ability to identify service-level COIN elements will
              allow for routing service requests to those COIN elements,
              including PNDs, therefore possibly allowing for a new COIN
              functionality to be included in the mobile application.</t>
            </li>
            <li>
              <t>The support for constraint-based selection of a specific
              (COIN) program instance over others (constraint-based (e.g., constraint-based routing in
              <xref target="APPCENTRES"/>, target="I-D.sarathchandra-coin-appcentres"/>, showcased
              for PNDs in <xref target="SarNet2021"/>) may allow for a more
              flexible and app-specific selection of (COIN) program instances,
              thereby allowing for better meeting the app-specific and end user end-user requirements.</t>
</list></t>
            </li>
          </ul>
        </section>
        <section anchor="mobileOffloadRQ"><name>Research anchor="mobileOffloadRQ">
          <name>Research Questions</name>

<t><list style="symbols">
  <t>RQ

          <ul spacing="normal">
            <li>RQ 3.1.1: How to combine service-level orchestration
            frameworks, such as TOSCA orchestration templates<xref templates <xref
            target="TOSCA"/>, with app-level, e.g., app-level (e.g., mobile application, application)
            packaging methods, ultimately providing the means for packaging micro-services
            microservices for deployments in distributed networked computing environments?</t>
  <t>RQ
            environments?</li>
            <li>RQ 3.1.2: How to reduce latencies involved in (COIN) program
            interactions where (COIN) program instance locations may change
            quickly? Can service-level requests be routed directly through
            in-band signalling signaling methods instead of relying on out-of-band
            discovery, such as through the DNS?</t>
  <t>RQ DNS?</li>
            <li>RQ 3.1.3: How to signal constraints used for routing requests
            towards (COIN) program instances in a scalable manner, i.e., manner (i.e., for
            dynamically choosing the best possible service sequence of one or
            more (COIN) programs for a given application experience through
            chaining (COIN) program executions?</t>
  <t>RQ executions)?</li>
            <li>RQ 3.1.4: How to identify (COIN) programs and program
            instances so as to allow routing (service) requests to specific
            instances of a given service?</t>
  <t>RQ service?</li>
            <li>RQ 3.1.5: How to identify a specific choice of a (COIN) program instances
            instance over others, thus allowing to pin pinning the execution of a
            service of a specific (COIN) program to a specific resource, i.e., resource (i.e., a
            (COIN) program instance in the distributed environment?</t>
  <t>RQ environment)?</li>
            <li>RQ 3.1.6: How to provide affinity of service requests towards
            (COIN) program instances, i.e., instances (i.e., longer-term transactions with
            ephemeral state established at a specific (COIN) program instance?</t>
  <t>RQ
            instance)?</li>
            <li>RQ 3.1.7: How to provide constraint-based routing decisions
            that can be realized at packet forwarding speed, e.g., speed (e.g., using
            techniques explored in <xref target="SarNet2021"/> at the
            forwarding plane or using approaches like <xref
            target="Multi2020"/> for extended routing protocols?</t>
  <t>RQ protocols)?</li>
            <li>RQ 3.1.8: What COIN capabilities may support the execution of
            (COIN) programs and their instances?</t>
  <t>RQ instances?</li>
            <li>RQ 3.1.9: How to ensure real-time synchronization and
            consistency of distributed application states among (COIN) program
            instances, in particular particular, when frequently changing the choice for a
            particular (COIN) program in terms of executing a service instance?</t>
</list></t>
            instance?</li>
          </ul>

        </section>
      </section>
      <section anchor="XR"><name>Extended anchor="XR">
        <name>Extended Reality and Immersive Media</name>
        <section anchor="description-1"><name>Description</name> anchor="description-1">

<!-- [rfced] FYI, for readability, we made this into two sentences at
"that can benefit". Please review.

Original:
   XR is one example of the multisource-
   multidestination problem that combines video and haptics in
   interactive multi-party interactions under strict delay requirements
   that can benefit from a functional distribution that includes fog
   computing for local information processing, the edge for aggregation,
   and the cloud for image processing.

Current:
   XR is one example of the multisource-
   multidestination problem that combines video and haptics in
   interactive multiparty interactions under strict delay requirements.
   As such, XR can benefit from a functional distribution that includes
   fog computing for local information processing, the edge for
   aggregation, and the cloud for image processing.
-->

          <name>Description</name>
          <t>Extended reality Reality (XR) encompasses VR, Augmented Reality (AR) and
          Mixed Reality (MR).  It provides the basis for the metaverse and is
          the driver of a number of advances in interactive technologies.
          While initially associated with gaming and immersive entertainment,
          applications now include remote diagnosis, maintenance,
          telemedicine, manufacturing and assembly, intelligent agriculture,
          smart cities, and immersive classrooms.  XR is one example of the
          multisource-multidestination problem that combines video and haptics
          in interactive multi-party multiparty interactions under strict delay requirements that
          requirements. As such, XR can benefit from a functional distribution that
          includes fog computing for local information processing, the edge
          for aggregation, and the cloud for image processing.</t>

<!-- [rfced] Should "re-rerouting" be updated to "re-routing" here?

Original:
   More importantly, COIN can enable collaborative XR experiences, where
   multiple users interact in the same virtual space in real-time, regardless
   of their physical locations, by allowing resource discovery and
   re-rerouting of XR streams.

Perhaps:
   More importantly, COIN can enable collaborative XR experiences, where
   multiple users interact in the same virtual space in real time, regardless
   of their physical locations, by allowing resource discovery and
   re-routing of XR streams.
-->

          <t>XR stands to benefit significantly from computing capabilities in
          the network.  For example, XR applications can offload intensive
          processing tasks to edge servers, considerably reducing latency when
          compared to cloud-based applications and enhancing the overall user
          experience.  More importantly, COIN can enable collaborative XR
          experiences, where multiple users interact in the same virtual space
          in real-time, real time, regardless of their physical locations, by allowing
          resource discovery and re-rerouting of XR streams.  While not a
          feature of most XR implementations, this capability opens up new
          possibilities for remote collaboration, training, and entertainment.
          Furthermore, COIN can support dynamic content delivery, allowing XR
          applications to seamlessly adapt to changing environments and user
          interactions.  Hence, the integration of computing capabilities into
          the network architecture enhances the scalability, flexibility, and
          performance of XR applications by supplying telemetry and advanced
          stream management, paving the way for more immersive and interactive
          experiences.</t>
          <t>Indeed, XR applications require real-time interactivity for
          immersive and increasingly mobile applications with tactile and
          time-sensitive data.  Because high bandwidth is needed for high
          resolution images and local rendering for 3D images and holograms,
          strictly relying on cloud-based architectures, even with headset
          processing, limits some of its potential benefits in the
          collaborative space.  As a consequence, innovation is needed to
          unlock the full potential of XR.</t>
        </section>
        <section anchor="characterization-1"><name>Characterization</name> anchor="characterization-1">
          <name>Characterization</name>

<!-- [rfced] For clarity, may we update "not networked or distributed"
in the text below to be more descriptive?

Original:
   Hence, implementing such XR solutions necessitates substantial
   computational power and minimal latency, which, for now, has spurred the
   development of better headsets not networked or distributed solutions as
   factors like distance from cloud servers and limited bandwidth can still
   significantly lower application responsiveness.

Perhaps:
   Hence, implementing such XR solutions necessitates substantial
   computational power and minimal latency, which, for now, has spurred the
   development of better headsets, rather than spurring networked or
   distributed solutions, as factors like distance from cloud servers and
   limited bandwidth can still significantly lower application responsiveness.
-->

	  <t>As mentioned above, XR experiences, especially those
          involving collaboration, are difficult to deliver with a
          client-server cloud-based solution as solution. This is because they require a
          combination of multi-stream multistream aggregation, low delays and delay
          variations, means to recover from losses, and optimized caching and
          rendering as close as possible to the user at the network edge.
          Hence, implementing such XR solutions necessitates substantial
          computational power and minimal latency, which, for now, has spurred
          the development of better headsets not networked or distributed
          solutions as factors like distance from cloud servers and limited
          bandwidth can still significantly lower application responsiveness.
          Furthermore, when XR deals with sensitive information, XR
          applications must also provide a secure environment and ensure user
          privacy, which represent additional burdens for delay sensitive delay-sensitive
          applications.  Additionally, the sheer amount of data needed for and
          generated by the XR applications, such as video holography, put them
          squarely in the realm of data-driven applications that can use
          recent trend analysis and mechanisms, as well as machine learning learning,
          in order to find the optimal caching and processing solution and, ideally, and
          ideally reduce the size of the data that needs transiting through
          the network.  Other mechanisms, such as data filtering and
          reduction, and functional distribution and partitioning partitioning, are also
          needed to accommodate the low delay needs for the same
          applications.</t>

          <t>With functional decomposition as the goal of a better XR experience,
          the elements involved in a COIN XR implementation include:</t>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>the XR application residing in the headset,</t>
            </li>
            <li>
              <t>edge federation services that allow local devices to
              communicate with one another directly,</t>
  <t>egde
            </li>
            <li>
              <t>edge application servers that enable local processing but
              also intelligent stream aggregation to reduce bandwidth
              requirements,</t>
            </li>
            <li>
              <t>edge data networks to that allow precaching of information based
              on locality and usage,</t>
            </li>
            <li>
              <t>cloud-based services for image processing and application
              training, and</t>
            </li>
            <li>
              <t>intelligent 5G/6G core networks for managing advanced access
              services and providing performance data for XR stream
              management.</t>
</list></t>
            </li>
          </ul>
          <t>These characteristics of XR paired with the capabilities of COIN
          make it likely that COIN can help to realize XR over networks for
          collaborative applications.  In particular, COIN functions can
          enable the distribution of the service components across different
          nodes in the network.  For example, data filtering, image rendering,
          and video processing leveraging leverage different hardware capabilities with
          combinations of CPU CPUs and GPU Graphics Processing Units (GPUs) at the
          network edge and in the fog, where the content is consumed, consumed. These
          represent possible remedies for the high bandwidth demands of XR.
          Machine learning across the network nodes can better manage the data
          flows by distributing them over more adequate paths.  In order to
          provide adequate quality of experience, multi-variate multivariate and
          heterogeneous resource allocation and goal optimization problems
          need to be solved, likely requiring advanced analysis and articificial
          artificial intelligence.  For the purpose of this document, it is
          important to note that the use of COIN for XR does not imply a
          specific protocol but targets an architecture enabling the
          deployment of the services.  In this context, similar considerations
          as for <xref target="mobileAppOffload"/> apply.</t>
        </section>
        <section anchor="existing-solutions-1"><name>Existing anchor="existing-solutions-1">
          <name>Existing Solutions</name>

<!-- [rfced] We have added additional punctuation to the text below. Please
review these updates and confirm that they do not change your intended
meaning.

Original:
   Information Centric Networking (and related) approaches that combine
   publish subscribe and distributed storage are also very suited for the
   multisource-multidestination applications of XR.

Current:
   Information-centric networking (and related) approaches that combine,
   publish, subscribe, and distribute storage are also very suited for
   the multisource-multidestination applications of XR.
-->

<!-- [rfced] For clarity, may we change 'the discovery of' to 'discovering'?
This makes the action parallel with 'using' (in other words,
'they include discovering X and using them to do Y').

Original:
   Mechanisms aimed at enhancing the computational and storage capacities of
   mobile devices could also improve XR capabilities as they include the
   discovery of available servers within the environment and using them
   opportunistically to enhance the performance of interactive applications
   and distributed file systems.

Perhaps:
   Mechanisms aimed at enhancing the computational and storage capacities of
   mobile devices could also improve XR capabilities, as they include
   discovering available servers within the environment and using them
   opportunistically to enhance the performance of interactive applications
   and distributed file systems.
-->

<t>The XR field has profited from extensive research in the past
          years in gaming, machine learning, network telemetry, high
          resolution imaging, smart cities, and IoT.
Information Centric Networking the Internet of Things (IoT).
          Information-centric networking (and related) approaches that combine publish subscribe combine,
          publish, subscribe, and distributed distribute storage are also very suited for
          the multisource-multidestination applications of XR.  New AR/VR AR and VR
          headsets and glasses have continued to evolve towards autonomy with
          local computation capabilities, increasingly performing many much of the
          processing that is needed to render and augment the local images.
          Mechanisms aimed at enhancing the computational and storage
          capacities of mobile devices could also improve XR capabilities as
          they include the discovery of available servers within the
          environment and using them opportunistically to enhance the
          performance of interactive applications and distributed file
          systems.</t>
          <t>While there is still no specific COIN research in AR and VR, the
          need for network-support network support is important to offload some of the
          computations related to movement, multi-user multiuser interactions, and
          networked applications applications, notably in gaming but also in health <xref target="NetworkedVR"/>.<br />
          target="NetworkedVR"/>.  This new approach to networked AR/VR AR and VR is
          exemplified in <xref target="eCAR"/> by using synchronized messaging
          at the edge to share the information that all users need to
          interact.  In <xref target="CompNet2021"/> and <xref
          target="WirelessNet2024"/>, the offloading uses artificial intelligence Artificial
          Intelligence (AI) to assign the 5G resources necessary for the real time interactions
          real-time interactions, and one could think that implementing this
          scheme on a PND is essentially a natural next step.  Hence, as AR/VR/XR is AR,
          VR, and XR are increasingly becoming more interactive, the
          efficiency needed to implement novel applications will require some
          form or another of edge-core implementation and COIN support.</t>

<t>Summarizing,

<!-- [rfced] Would "federating systems capabilities" be more clear as
"the federation of systems capabilities" here?

Original:
   Yet, there are still very few interactive immersive media applications
   over networks that allow for federating systems capabilities.

Perhaps:
   Yet, there are still very few interactive immersive media applications
   over networks that allow for the federation of systems capabilities.
-->

<t>In summary, some XR solutions exist exist, and headsets continue to
          evolve to what is now claimed to be spatial computing.
          Additionally, with recent work on the Metaverse, metaverse, the number of
          publications related to XR has skyrocketed.  However, in terms of
          networking, which is the focus of this document, current deployments
          do not take advantage of network capabilities.  The information is
          rendered and displayed based on the local processing but does not
          readily discover the other elements in the vicinity or in the
          network that could improve its performance either locally, at the
          edge, or in the cloud.  Yet, there are still very few interactive and
          immersive media applications over networks that allow for federating
          systems capabilities.</t>
        </section>

        <section anchor="opportunities-1"><name>Opportunities</name> anchor="opportunities-1">
          <name>Opportunities</name>
          <t>While delay is inherently related to information transmission and transmission, if
          we continue the analogy of the computer board to highlight some of
          the COIN capabilities in terms of computation and storage but also
          allocation of resources, there are some opportunities that XR could
          take advantage of:</t>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>Round trip time: 20 ms is usually cited as an upper limit for
              XR applications. Storage and preprocessing of scenes in local
              elements (including in the mobile network) could extend the
              reach of XR applications at least over the extended edge.</t>
            </li>
            <li>
              <t>Video transmission: The use of better transcoding, advanced
              context-based compression algorithms, prefetching and
              precaching, as well as movement prediction all help to reduce
              bandwidth consumption. While this is now limited to local processing
              processing, it is not outside the realm of COIN to push some of
              these functionalities to the network network, especially as realted related to caching/fetching
              caching and fetching but also context based context-based flow direction and
              aggregation.</t>
            </li>
            <li>
              <t>Monitoring: Since bandwidth and data are fundamental for to XR
              deployment, COIN functionality could help to better monitor and
              distribute the XR services over collaborating network elements
              to optimize end-to-end performance.</t>
            </li>
            <li>
              <t>Functional decomposition: Advanced functional decomposition,
              localization, and discovery of computing and storage resources
              in the network can help to optimize user experience in
              general.</t>
            </li>
            <li>
              <t>Intelligent network management and configuration: The move to artificial intelligence
              AI in network management to learn about
              flows and adapt resources based on both data plane and control
              plane programmability can help the overall deployment of XR
              services.</t>
</list></t>
            </li>
          </ul>
        </section>
<!-- [rfced] For readability and clarity of RQ 3.2.3

a) Is this about two separate research questions ("the use of distributed AI"
and "the creation of semi-permanent datasets")? May they be two separate
sentences?

b) May we adjust "resulting in" to "result in" to add a clear verb to the
second half of this text?

Original:
   *  RQ 3.2.3: Can the use of distributed AI algorithms across both
      data center and edge computers be leveraged for creating optimal
      function allocation and the creation of semi-permanent datasets
      and analytics for usage trending and flow management resulting in
      better localization of XR functions?

Perhaps:
   *  RQ 3.2.3: Can the use of distributed AI algorithms across both
      data center and edge computers be leveraged for creating optimal
      function allocation? Can the creation of semi-permanent datasets
      and analytics for usage trending and flow management result in
      better localization of XR functions?
-->

<!-- [rfced] For ease of the reader, may we break this one sentence into two?
In addition, may we update the verb "optimize" to "optimizing" as follows?

Original:
   *  RQ 3.2.4: Can COIN improve the dynamic distribution of control,
      forwarding, and storage resources and related usage models in XR,
      such as to integrate local and fog caching with cloud-based pre-
      rendering, thus jointly optimizing COIN and higher layer protocols
      to reduce latency and, more generally, manage the quality of XR
      sessions, e.g., through reduced in-network congestion and improved
      flow delivery by determining how to prioritize XR data?

Perhaps:
   *  RQ 3.2.4: Can COIN improve the dynamic distribution of control,
      forwarding, and storage resources and related usage models in XR,
      such as to integrate local and fog caching with cloud-based pre-
      rendering? Could this jointly optimize COIN and higher layer protocols to
      reduce latency and, more generally, manage the quality of XR sessions
      (e.g., through reduced in-network congestion and improved flow delivery
      by determining how to prioritize XR data)?
-->
        <section anchor="research-questions"><name>Research anchor="research-questions">
          <name>Research Questions</name>

<t><list style="symbols">
  <t>RQ
          <ul spacing="normal">
            <li>RQ 3.2.1: Can current PNDs provide the speed required for
            executing complex filtering operations, including metadata
            analysis for complex and dynamic scene rendering?</t>
  <t>RQ rendering?</li>
            <li>RQ 3.2.2: Where should PNDs equipped with these operations be
            located for optimal performance gains?</t>
  <t>RQ gains?</li>
	    <li>RQ 3.2.3: Can the use of distributed AI algorithms across both
            data center and edge computers be leveraged for creating optimal
            function allocation and the creation of semi-permanent datasets
            and analytics for usage trending and flow management resulting in
            better localization of XR functions?</t>
  <t>RQ functions?</li>
            <li>RQ 3.2.4: Can COIN improve the dynamic distribution of
            control, forwarding, and storage resources and related usage
            models in XR, such as to integrate local and fog caching with
            cloud-based pre-rendering, thus jointly optimizing COIN and higher
            layer protocols to reduce latency and, more generally, manage the
            quality of XR sessions, e.g., sessions (e.g., through reduced in-network
            congestion and improved flow delivery by determining how to
            prioritize XR data?</t>
  <t>RQ data)?</li>
            <li>RQ 3.2.5: Can COIN provide the necessary infrastructure for
            the use of interactive XR everywhere? Particularly, how can a COIN
            system enable the joint collaboration across all segments of the
            network (fog, edge, core, and cloud) to support functional
            decompositions, including using edge resources without the need
            for a (remote) cloud connection?</t>
  <t>RQ connection?</li>
            <li>RQ 3.2.6: How can COIN systems provide multi-stream multistream efficient
            transmission and stream combining at the edge, including the
            ability to dynamically include extra streams, such as audio and
            extra video tracks?</t>
</list></t> tracks?</li>
          </ul>
        </section>

        <section anchor="additional-desirable-capabilities"><name>Additional anchor="additional-desirable-capabilities">
          <name>Additional Desirable Capabilities</name>
          <t>In addition to the capabilities driven by the research questions
          above, there are a number of other features that solutions in this
          space might benefit from.  In particular, the provided XR experience
          should be optimized both in the amount of transmitted data, while
          equally optimizing loss protection.  Furthermore, the means for trend
          analysis and telemetry to measure performance may foster uptake of
          the XR services, while the interaction of the XR system with indoor
          and outdoor positioning systems may improve on service experience
          and user perception.</t>
        </section>
      </section>
      <section anchor="PerformingArts"><name>Personalized anchor="PerformingArts">
        <name>Personalized and interactive performing arts</name> Interactive Performing Arts</name>
        <section anchor="description-2"><name>Description</name> anchor="description-2">
          <name>Description</name>
          <t>This use case is a deeper dive into a specific scenario of the
          immersive and extended reality class of use cases discussed in
          <xref target="XR"/>.  It focuses on live productions of the
          performing arts where the performers and audience members are
          geographically distributed.  The performance is conveyed through
          multiple networked streams streams, which are tailored to the requirements
          of the remote performers, the director, the sound and lighting
          technicians, and the individual audience members; performers members. Performers need to
          observe, interact interact, and synchronize with other performers in remote locations;
          locations, and the performers receive live feedback from the
          audience, which may also be conveyed to other audience members.</t>

          <t>There are two main aspects: i) to aspects:</t>
	  <ol type="i">
	    <li>to emulate as closely as possible the experience of live
	    performances where the performers, audience, director, and
	    technicians are co-located in the same physical space, such as a
	    theater; and ii) to and</li>
	    <li>to enhance traditional physical performances with features
	    such as personalization of the experience according to the
	    preferences or needs of the performers, directors, and audience members.</t>
	    members.</li>
	  </ol>

          <t>Examples of personalization include:</t>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>Viewpoint selection selection, such as choosing a specific seat in the
              theater or for more advanced positioning of the audience
              member's viewpoint outside of the traditional seating - (i.e.,
              amongst, above, or behind the performers (but performers, but within some limits which
              that may be imposed by the performers or the director, director for
              artistic reasons);</t>
  <t>Augmentation
            </li>
<!--[rfced] FYI, this text has been updated to use person-first language.
Please let us know if you prefer otherwise.

Original:
   *  Augmentation of the performance with subtitles, audio-description,
      actor-tagging, language translation, advertisements/product-placement, advertisements/product-
      placement, other enhancements/filters to make the performance
      accessible to disabled audience members (removal of flashing
      images for epileptics, alternative color schemes for color-blind
      audience members, etc.).</t>
</list></t> etc.).

Current:
   *  Augmentation of the performance with subtitles, audio description,
      actor tagging, language translation, advertisements and product
      placement, and other enhancements and filters to make the
      performance accessible to audience members who are disabled (e.g.,
      the removal of flashing images for audience members who have
      epilepsy or alternative color schemes for those who have color
      blindness).
-->
            <li>
              <t>Augmentation of the performance with subtitles, audio
              description, actor tagging, language translation, advertisements
              and product placement, and other enhancements and filters to
              make the performance accessible to audience members who are disabled
              (e.g., the removal of flashing images for audience members who have epilepsy or alternative color
              schemes for those who have color blindness).</t>
            </li>
          </ul>
        </section>

        <section anchor="characterization-2"><name>Characterization</name> anchor="characterization-2">
          <name>Characterization</name>
          <t>There are several chained functional entities which that are
          candidates for being deployed as (COIN) programs:</t>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>Performer aggregation and editing functions</t>
            </li>
            <li>
              <t>Distribution and encoding functions</t>
            </li>
            <li>
              <t>Personalization functions
  <list style="symbols">
              </t>
              <ul spacing="normal">
                <li>
                  <t>to select which of the existing streams should be
                  forwarded to the audience member, remote performer, or
                  member of the production team</t>
                </li>
                <li>
                  <t>to augment streams with additional metadata such as subtitles</t>
                </li>
                <li>
                  <t>to create new streams after processing existing ones, e.g., ones
                  (e.g., to interpolate between camera angles to create a new
                  viewpoint or to render point clouds from an audience
                  member's chosen perspective</t> perspective)</t>
                </li>
                <li>
                  <t>to undertake remote rendering according to viewer position, e.g.,
                  position (e.g., the creation of VR headset display streams
                  according to audience head position - position) when this processing
                  has been offloaded from the viewer's end-system end system to the COIN
                  function due to limited processing power in the end-system, end system
                  or due to limited network bandwidth to receive all of the
                  individual streams to be processed.</t>
    </list></t>
                </li>
              </ul>
            </li>
            <li>
              <t>Audience feedback sensor processing functions</t>
            </li>
            <li>
              <t>Audience feedback aggregation functions</t>
</list></t>
            </li>
          </ul>
          <t>These are candidates for deployment as (COIN) Programs programs in PNDs
          rather than being located in end-systems end systems (at the performers' site,
          the audience members' premises premises, or in a central cloud location) for
          several reasons:</t>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>Personalization of the performance according to viewer
              preferences and requirements makes it infeasible to be done in a
              centralized manner at the performer premises: the computational
              resources and network bandwidth would need to scale with the
              number of personalized streams.</t>
            </li>
            <li>
              <t>Rendering of VR headset content to follow viewer head
              movements has an upper bound on lag to maintain viewer QoE, Quality of Experience (QoE),
              which requires the processing to be undertaken sufficiently
              close to the viewer to avoid large network latencies.</t>
            </li>
            <li>
              <t>Viewer devices may not have the processing-power processing power to perform
              the personalization tasks, or the viewers' network may not have
              the capacity to receive all of the constituent streams to
              undertake the personalization functions.</t>
            </li>
            <li>
              <t>There are strict latency requirements for live and
              interactive aspects that require the deviation from the direct
              network path between performers and audience members to be
              minimized, which reduces the opportunity to route streams via
              large-scale processing capabilities at centralized data-centers.</t>
</list></t>
              data centers.</t>
            </li>
          </ul>
        </section>
        <section anchor="existing-solutions-2"><name>Existing solutions</name> anchor="existing-solutions-2">
          <name>Existing Solutions</name>
          <t>Note: Existing solutions for some aspects of this use case are
          covered in <xref target="mobileAppOffload"/>, <xref target="XR"/>,
          and <xref target="CDNs"/>.</t>
        </section>
        <section anchor="opportunities-2"><name>Opportunities</name>

<t><list style="symbols"> anchor="opportunities-2">
          <name>Opportunities</name>

          <ul spacing="normal">
            <li>
              <t>Executing media processing and personalization functions
              on-path as (COIN) Programs programs in PNDs can avoid detour/stretch to
              central servers, thus reducing latency and bandwidth
              consumption.  For example, the overall delay for performance
              capture, aggregation, distribution, personalization,
              consumption, capture of audience response, feedback processing,
              aggregation, and rendering should be achieved within an upper
              bound of latency (the tolerable amount is to be defined, but in
              the order of 100s of ms to mimic performers perceiving audience
              feedback, such as laughter or other emotional responses in a
              theater setting).</t>
            </li>
            <li>
              <t>Processing of media streams allows (COIN) Programs, PNDs programs, PNDs, and
              the wider (COIN) System/Environment system/environment to be contextually aware of
              flows and their requirements requirements, which can be used for determining
              network treatment of the flows, e.g., flows (e.g., path selection,
              prioritization, multi-flow multiflow coordination, synchronization synchronization, and resilience.</t>
</list></t>
              resilience).</t>
            </li>
          </ul>
        </section>
        <section anchor="research-questions-1"><name>Research Questions:</name>

<t><list style="symbols"> anchor="research-questions-1">
          <name>Research Questions</name>
          <ul spacing="normal">
            <li>
              <t>RQ 3.3.1: In which PNDs should (COIN) Programs programs for
              aggregation, encoding, and personalization functions be located?
              Close to the performers or close to the viewers?</t>
            </li>
            <li>
              <t>RQ 3.3.2: How far from the direct network path from performer
              to viewer should (COIN) programs be located, considering the
              latency implications of path-stretch and the availability of
              processing capacity at PNDs? How should tolerances be defined by
              users?</t>
            </li>
            <li>
              <t>RQ 3.3.3: Should users decide which PNDs should be used for
              executing (COIN) Programs programs for their flows flows, or should they express
              requirements and constraints that will direct decisions by the
              orchestrator/manager of a COIN System? system? In case of the latter,
              how can users specify requirements on network and processing
              metrics (such as latency and throughput bounds)?</t>
            </li>
            <li>
	      <t>RQ 3.3.4: How to achieve synchronization across multiple
	      streams to allow for merging, audio-video interpolation, and
	      other cross-stream processing functions that require time
	      synchronization for the integrity of the output?  How can this
	      be achieved considering that synchronization may be required
	      between flows that are: i) on are:</t>
		<ol type="i">
		<li>
		  <t>on the same data pathway through a PND/router, ii) arriving/leaving PND/router,</t>
		</li>
		<li>
		  <t>arriving/leaving through different ingress/egress
		  interfaces of the same PND/router, iii) routed or</t>
		</li>
		<li>
		  <t>routed through disjoint paths through different PNDs/routers?
This PNDs/routers?</t>
		</li>
	        </ol>
		<t>This RQ raises issues associated with synchronisation synchronization
		across multiple media streams and sub-streams substreams <xref
		target="RFC7272"/> as well as time synchronisation synchronization between
		PNDs/routers on multiple paths <xref
		target="RFC8039"/>.</t>
            </li>
            <li>
              <t>RQ 3.3.5: Where will COIN Programs programs be executed? In the data-plane
              data plane of PNDs, in other on-router computational
              capabilities within PNDs, or in adjacent computational
              nodes?</t>
            </li>
            <li>
              <t>RQ 3.3.6: Are computationally-intensive tasks - computationally intensive tasks, such as video
              stitching or media recognition and annotation (cf. <xref target="XR"/>) -
              target="XR"/>), considered as suitable candidate (COIN) Programs
              programs or should they be implemented in end-systems?</t> end systems?</t>
            </li>
            <li>
              <t>RQ 3.3.7: If the execution of COIN Programs programs is offloaded to
              computational nodes outside of PNDs, e.g., PNDs (e.g., for processing by GPUs,
              GPUs), should this still be considered as COIN? Where is the
              boundary between COIN capabilities and explicit routing of flows
              to endsystems?</t>
</list></t> end systems?</t>
            </li>
          </ul>
        </section>

        <section anchor="additional-desirable-capabilities-1"><name>Additional anchor="additional-desirable-capabilities-1">
          <name>Additional Desirable Capabilities</name>
          <t>In addition to the capabilities driven by the research questions
          above, there are a number of other features that solutions in this
          space might benefit from.  In particular, if users are indeed
          empowered to specify requirements on network and processing metrics,
          one important capability of COIN systems will be to respect these
          user-specified requirements and constraints when routing flows and
          selecting PNDs for executing (COIN) Programs. programs.  Similarly, solutions
          should be able to synchronize flow treatment and processing across
          multiple related flows flows, which may be on disjoint paths paths, to provide
          similar performance to different entities.</t>
        </section>
      </section>
    </section>

    <section anchor="newEnvironments"><name>Supporting new anchor="newEnvironments">
      <name>Supporting New COIN Systems</name>

      <section anchor="control"><name>In-Network anchor="control">
        <name>In-Network Control / Time-sensitive applications</name> Time-Sensitive Applications</name>

        <section anchor="description-3"><name>Description</name> anchor="description-3">
          <name>Description</name>
          <t>The control of physical processes and components of industrial
          production lines is essential for the growing automation of
          production and ideally allows for a consistent quality level.
          Traditionally, the control has been exercised by control software
          running on programmable logic controllers Programmable Logic Controllers (PLCs) located directly
          next to the controlled process or component.  This approach is best-suited
          best suited for settings with a simple model that is focused on a
          single or a few controlled components.</t>
          <t>Modern production lines and shop floors are characterized by an
          increasing number of involved devices and sensors, a growing level
          of dependency between the different components, and more complex
          control models.  A centralized control is desirable to manage the
          large amount of available information information, which often has to be
          preprocessed or aggregated with other information before it can be
          used.  As a result, computations are increasingly spatially
          decoupled and moved away from the controlled objects, thus inducing
          additional latency.
Instead  Instead, moving compute functionality onto COIN
          execution environments inside the network offers a new solution
          space to these challenges, providing new compute locations with much
          smaller latencies.</t>
        </section>

        <section anchor="characterization-3"><name>Characterization</name> anchor="characterization-3">
          <name>Characterization</name>
          <t>A control process consists of two main components as illustrated
          in <xref target="processControl"/>: a system under control and a
          controller.  In feedback control, the current state of the system is monitored, e.g.,
          monitored (e.g., using sensors, sensors), and the controller influences the
          system based on the difference between the current and the reference
          state to keep it close to this reference state.</t>

          <figure title="Simple feedback control model." anchor="processControl"><artwork><![CDATA[ anchor="processControl">
            <name>Simple Feedback Control Model</name>
            <artwork><![CDATA[
 reference
   state      ------------        --------    Output
---------->  | Controller | ---> | System | ---------->
           ^  ------------        --------       |
           |                                     |
           |   observed state                    |
           |                    ---------        |
            -------------------| Sensors | <-----
                                ---------
]]></artwork></figure>
]]></artwork>
          </figure>
          <t>Apart from the control model, the quality of the control
          primarily depends on the timely reception of the sensor feedback feedback,
          which can be subject to tight latency constraints, often in the
          single-digit millisecond range.  Even shorter feedback requirements
          may exist in other use cases, such as interferometry or high-energy
          physics, but these use cases are out of scope for this document.
          While low latencies are essential, there is an even greater need for
          stable and deterministic levels of latency, because controllers can
          generally cope with different levels of latency, latency if they are
          designed for them, but they are significantly challenged by
          dynamically changing or unstable latencies.  The unpredictable
          latency of the Internet exemplifies this problem if, e.g., for example,
          off-premise cloud platforms are included.</t>
        </section>
        <section anchor="existing-solutions-3"><name>Existing anchor="existing-solutions-3">
          <name>Existing Solutions</name>
          <t>Control functionality is traditionally executed on PLCs close to
          the machinery.  These PLCs typically require vendor-specific
          implementations and are often hard to upgrade and update update, which makes
          such control processes inflexible and difficult to manage.  Moving
          computations to more freely programmable devices thus has the
          potential of significantly improving the flexibility.  In this
          context, directly moving control functionality to (central) cloud
          environments is generally possible, yet only feasible if latency
          constraints are lenient.</t>
          <t>Early approaches such as <xref target="RUETH"/> target="RÜTH"/> and <xref
          target="VESTIN"/> have already shown the general applicability of
          leveraging COIN for in-network control.</t>
        </section>
        <section anchor="opportunities-3"><name>Opportunities</name>

<t><list style="symbols"> anchor="opportunities-3">
          <name>Opportunities</name>
          <ul spacing="normal">
            <li>
              <t>Performing simple control logic on PNDs and/or in COIN
              execution environments can bring the controlled system and the
              controller closer together, possibly satisfying the tight
              latency requirements.</t>
            </li>
            <li>
              <t>Creating a coupled control that is exercised via (i) simplified via</t>
      	      <ol type="i">
		<li>
		  <t>simplified approximations of more complex control
		  algorithms deployed in COIN execution environments, and (ii) more and</t>
		</li>
	      	<li>
		  <t>more complex overall control schemes deployed in the cloud can cloud</t>
		</li>
	      </ol>
	      <t>can allow for quicker, yet more inaccurate responses from
	      within the network while still providing for sufficient control
	      accuracy at higher latencies from afar.</t>
</list></t>
            </li>
          </ul>
        </section>
        <section anchor="research-questions-2"><name>Research anchor="research-questions-2">
          <name>Research Questions</name>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>RQ 4.1.1: How to derive simplified versions of the global
              (control) function?</t>
            </li>
            <li>
              <t>RQ 4.1.2: How to account for the limited computational
              precision of PNDs that typically only allow for integer
              precision computation for enabling high processing rates rates, while
              floating-point precision is needed by most control algorithms
              (cf. <xref target="KUNZE-APPLICABILITY"/>)?</t>
            </li>
            <li>
              <t>RQ 4.1.3: How to find suitable tradeoffs regarding simplicity
              of the control function ("accuracy of the control") and
              implementation complexity ("implementability")?</t>
            </li>
            <li>
              <t>RQ 4.1.4: How to (dynamically) distribute simplified versions
              of the global (control) function among COIN execution
              environments?</t>
            </li>
            <li>
              <t>RQ 4.1.5: How to (dynamically) (re-)compose compose or recompose the distributed
              control functions?</t>
            </li>

<!-- [rfced] For clarity, may we adjust this list as follows?

Original:
   *  RQ 4.1.6: Can there be different control levels, e.g., "quite
      inaccurate & very low latency" (PNDs, deep in the network), "more
      accurate & higher latency" (more powerful COIN execution
      environments, farer away), "very accurate & very high latency"
      (cloud environments, far away)?

Option A (without parentheses):
    *  RQ 4.1.6: Can there be different control levels? For example,
       "quite inaccurate & very low latency" for PNDs deep in the network;
       "more accurate & higher latency" for more powerful COIN execution
       environments that are farther away; and "very accurate & very high
       latency" for cloud environments that are far away.

Option B (using a sublist):
   *  RQ 4.1.6: Can there be different control levels?  For example:

      -  "quite inaccurate & very low latency" for PNDs deep in the
         network;
      -  "more accurate & higher latency" for more powerful COIN execution
         environments that are farther away; and
      -  "very accurate & very high latency" for cloud environments that
         are far away.
-->

            <li>
              <t>RQ 4.1.6: Can there be different control levels, e.g., "quite
              inaccurate &amp; very low latency" (PNDs, deep in the network),
              "more accurate &amp; higher latency" (more powerful COIN
              execution environments, farer farther away), "very accurate &amp; very
              high latency" (cloud environments, far away)?</t> </li> <li>
              <t>RQ 4.1.7: Who decides which control instance is executed and
              which information can be used for this decision?</t>
            </li>
            <li>
              <t>RQ 4.1.8: How do the different control instances interact and
              how can we define their hierarchy?</t>
</list></t>
            </li>
          </ul>
        </section>
        <section anchor="additional-desirable-capabilities-2"><name>Additional anchor="additional-desirable-capabilities-2">
          <name>Additional Desirable Capabilities</name>
          <t>In addition to the capabilities driven by the research questions
          above, there are a number of other features that approaches
          deploying control functionality in COIN execution environments could
          benefit from.  For example, having an explicit interaction between
          the COIN execution environments and the global controller would
          ensure that it is always clear which entity is emitting which
          signals.  In this context, it is also important that actions of COIN
          execution environments are overridable by the global controller such
          that the global controller has the final say in the process
          behavior.  Finally, by accommodating the general characteristics of
          control approaches, functions in COIN execution environments should
          ideally expose reliable information on the predicted delay and must
          expose reliable information on the predicted accuracy to the global
          control such that these aspects can be accommodated in the overall
          control.</t>
        </section>
      </section>
      <section anchor="filtering"><name>Large Volume anchor="filtering">
        <name>Large-Volume Applications</name>
        <section anchor="FilteringDesc"><name>Description</name> anchor="FilteringDesc">
          <name>Description</name>
          <t>In modern industrial networks, processes and machines are
          extensively monitored by distributed sensors with a large spectrum
          of capabilities, ranging from simple binary (e.g., light barriers)
          to sophisticated sensors with varying degrees of resolution.
          Sensors further serve different purposes, as some are used for
          time-critical process control control, while others represent redundant
          fallback platforms.  Overall, there is a high level of heterogeneity heterogeneity,
          which makes managing the sensor output a challenging task.</t>
          <t>Depending on the deployed sensors and the complexity of the
          observed system, the resulting overall data volume can easily be in
          the range of several Gbit/s <xref target="GLEBKE"/>.  These volumes
          are often already difficult to handle in local environments environments, and it
          becomes even more challenging when off-premise clouds are used for
          managing the data.  While large networking companies can simply
          upgrade their infrastructure to accommodate the accruing data
          volumes, most industrial companies operate on tight infrastructure
          budgets such that frequently upgrading is not always feasible or
          possible.  Hence, a major challenge is to devise a methodology that
          is able to handle such amounts of data efficiently and flexibily flexibly
          without relying on recurring infrastructure upgrades.</t>
          <t>Data filtering and preprocessing, similar to the considerations
          in <xref target="XR"/>, can be building blocks for new solutions in
          this space.  Such solutions, however, might also have to address the
          added challenge of business data leaving the premises and control of
          the company.  As this data could include sensitive information or
          valuable business secrets, additional security measures have to be
          taken.  Yet, typical security measures such as encrypting the data
          make filtering or preprocessing approaches hardly applicable as they
          typically work on unencrypted data.  Consequently, incorporating
          security into these approaches, either by adding functionality for
          handling encrypted data or devising general security measures, is an
          additional auspicious field for research.</t>
        </section>
        <section anchor="FilteringChar"><name>Characterization</name> anchor="FilteringChar">
          <name>Characterization</name>
          <t>In essence, the described monitoring systems consist of sensors
          that produce large volumes of monitoring data.  This data is then
          transmitted to additional components that provide data processing
          and analysis capabilities or simply store the data in large data
          silos.</t>
          <t>As sensors are often set up redundantly, parts of the collected
          data might also be redundant.  Moreover, sensors are often hard to
          configure or not configurable at all all, which is why their resolution
          or sampling frequency is often larger than required.  Consequently,
          it is likely that more data is transmitted than is needed or
          desired, prompting the deployment of filtering techniques.  For
          example, COIN programs deployed in the on-premise network could
          filter out redundant or undesired data before it leaves the premise
          using simple traffic filters, thus reducing the required (upload)
          bandwidths.  The available sensor data could be scaled down using
          standard statistical sampling, packet-based sub-sampling, i.e., sub-sampling (i.e., only
          forwarding every n-th packet, packet), or using filtering as long as the
          sensor value is in an uninteresting range while forwarding with a
          higher resolution once the sensor value range becomes interesting
          (cf. <xref target="KUNZE-SIGNAL"/>).  While the former variants are
          oblivious to the semantics of the sensor data, the latter variant
          requires an understanding of the current sensor levels.  In any
          case, it is important that end-hosts end hosts are informed about the
          filtering so that they can distinguish between data loss and data
          filtered out on purpose.</t>
          <t>In practice, the collected data is further processed using
          various forms of computation.  Some of them are very complex or need
          the complete sensor data during the computation, but there are also
          simpler operations which that can already be done on subsets of the
          overall dataset or earlier on the communication path as soon as all
          data is available.  One example is finding the maximum of all sensor values
          values, which can either be done iteratively at each intermediate hop
          or at the first hop, hop where all data is available.  Using expert
          knowledge about the exact computation steps and the concrete
          transmission path of the sensor data, simple computation steps can
          thus be deployed in the on-premise network, again reducing the
          overall data volume.</t>
        </section>
        <section anchor="FilteringSol"><name>Existing anchor="FilteringSol">
          <name>Existing Solutions</name>
          <t>Current approaches for handling such large amounts of information
          typically build upon stream processing frameworks such as Apache
          Flink.  These solutions allow for handling large volume large-volume applications
          and map the compute functionality to performant server machines or
          distributed compute platforms.  Augmenting the existing
          capabilities, COIN offers a new dimension of platforms for such
          processing frameworks.</t>
        </section>
        <section anchor="FilteringOppo"><name>Opportunities</name>

<t><list style="symbols"> anchor="FilteringOppo">
          <name>Opportunities</name>
          <ul spacing="normal">
            <li>
              <t>(Stream) processing frameworks can become more flexible by
              introducing COIN execution environments as additional deployment
              targets.</t>
            </li>
            <li>
              <t>(Semantic) packet filtering based on packet header and
              payload, as well as multi-packet multipacket information can (drastically)
              reduce the data volume, possibly even without losing any
              important information.</t>
            </li>
            <li>
              <t>(Semantic) data (pre-)processing, e.g., preprocessing and processing (e.g., in the form of
              computations across multiple packets and potentially leveraging
              packet payload, payload) can also reduce the data volume without losing
              any important information.</t>
</list></t>
            </li>
          </ul>
        </section>
        <section anchor="FilteringRQ"><name>Research anchor="FilteringRQ">
          <name>Research Questions</name>
          <t>Some of the following research questions are also relevant in the
          context of general stream processing systems.</t>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>RQ 4.2.1: How can the overall data processing pipeline be
              divided into individual processing steps that could then be
              deployed as COIN functionality?</t>
            </li>
            <li>
              <t>RQ 4.2.2: How to design COIN programs for (semantic) packet
              filtering and which filtering criteria make sense?</t>
            </li>
            <li>
              <t>RQ 4.2.3: Which kinds of COIN programs can be leveraged for (pre-)processing
              (pre)processing steps and what complexity can they have?</t>
            </li>
            <li>
              <t>RQ 4.2.4: How to distribute and coordinate COIN programs?</t>
            </li>
            <li>
              <t>RQ 4.2.5: How to dynamically reconfigure and recompose COIN programs?</t>
            </li>
            <li>
              <t>RQ 4.2.6: How to incorporate the (pre-)processing (pre)processing and
              filtering steps into the overall system?</t>
            </li>
            <li>
              <t>RQ 4.2.7: How can changes to the data by COIN programs be
              signaled to the end-hosts?</t>
</list></t> end hosts?</t>
            </li>
          </ul>
        </section>
        <section anchor="FilteringReq"><name>Additional anchor="FilteringReq">
          <name>Additional Desirable Capabilities</name>
          <t>In addition to the capabilities driven by the research questions
          above, there are a number of other features that such large volume large-volume
          applications could benefit from.  In particular, conforming to
          standard application-level syntax and semantics likely simplifies
          embedding filters and preprocessors into the overall system.  If
          these filters and preprocessors also leverage packet header and
          payload information for their operation, this could further improve
          the performance of any approach developed based on the above
          research questions.</t>
        </section>
      </section>
      <section anchor="safety"><name>Industrial anchor="safety">
        <name>Industrial Safety</name>
        <section anchor="description-4"><name>Description</name> anchor="description-4">
          <name>Description</name>
          <t>Despite an increasing automation in production processes, human
          workers are still often necessary.  Consequently, safety measures
          have a high priority to ensure that no human life is endangered.  In
          traditional factories, the regions of contact between humans and
          machines are well-defined well defined and interactions are simple.  Simple
          safety measures like emergency switches at the working positions are
          enough to provide a good level of safety.</t>
          <t>Modern factories are characterized by increasingly dynamic and
          complex environments with new interaction scenarios between humans
          and robots.  Robots can directly assist humans, perform tasks
          autonomously, or even freely move around on the shopfloor. shop floor.  Hence,
          the intersect between the human working area and the robots grows grows,
          and it is harder for human workers to fully observe the complete
          environment.  Additional safety measures are essential to prevent
          accidents and support humans in observing the environment.</t>
        </section>
        <section anchor="characterization-4"><name>Characterization</name> anchor="characterization-4">
          <name>Characterization</name>
          <t>Industrial safety measures are typically hardware solutions
          because they have to pass rigorous testing before they are certified
          and deployment-ready. deployment ready.  Standard measures include safety switches and
          light barriers.  Additionally, the working area can be explicitly
          divided into 'contact' "contact" and 'safe' "safe" areas, indicating when workers
          have to watch out for interactions with machinery.  For example,
          markings on the factory floor can show the areas where robots move
          or indicate their maximum physical reach.</t>
          <t>These measures are static solutions, potentially relying on
          specialized hardware, and are challenged by the increased dynamics
          of modern factories where the factory configuration can be changed
          on demand or where all entities are freely moving around.  Software
          solutions offer higher flexibility as they can dynamically respect
          new information gathered by the sensor systems, but in most cases
          they cannot give guaranteed safety.  COIN systems could leverage the
          increased availability of sensor data and the detailed monitoring of
          the factories to enable additional safety measures with shorter
          response times and higher guarantees.  Different safety indicators
          within the production hall could be combined within the network so
          that PNDs can give early responses if a potential safety breach is
          detected.  For example, the positions of human workers and robots
          could be tracked tracked, and robots could be stopped when they get too close
          to a human in a non-working area or if a human enters a defined
          safety zone.  More advanced concepts could also include image data
          or combine arbitrary sensor data.  Finally, the increasing
          softwarization of industrial processes can also lead to new
          problems, e.g., if software bugs cause unintended movements of
          robots.  Here, COIN systems could independently double check issued
          commands to void unsafe commands.</t>
        </section>
        <section anchor="existing-solutions-4"><name>Existing anchor="existing-solutions-4">
          <name>Existing Solutions</name>
          <t>Due to the importance of safety, there is a wide range of
          software-based approaches aiming at enhancing security.  One example
          are tag-based systems, e.g., systems (e.g., using RFID, RFID), where drivers of forklifts
          can be warned if pedestrian workers carrying tags are nearby.  Such
          solutions, however, require setting up an additional system and do
          not leverage existing sensor data.</t>
        </section>
        <section anchor="opportunities-4"><name>Opportunities</name>

<t><list style="symbols"> anchor="opportunities-4">
          <name>Opportunities</name>
          <ul spacing="normal">
            <li>
              <t>Executing safety-critical COIN functions on PNDs could allow
              for early emergency reactions based on diverse sensor feedback
              with low latencies.</t>
            </li>
            <li>
              <t>COIN software could provide independent on-path surveillance
              of control software-initiated actions to block unsafe
              commands.</t>
</list></t>
            </li>
          </ul>
        </section>
        <section anchor="research-questions-3"><name>Research anchor="research-questions-3">
          <name>Research Questions</name>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>RQ 4.3.1: Which additional safety measures can be provided
              and do they actually improve safety?</t>
            </li>
            <li>
              <t>RQ 4.3.2: Which sensor information can be combined and
              how?</t>
            </li>
            <li>
              <t>RQ 4.3.3: How can COIN-based safety measures be integrated
              with existing safety measures without degrading safety?</t>
            </li>
            <li>
              <t>RQ 4.3.4: How can COIN software validate control software-initated
              software-initiated commands to prevent unsafe operations?</t>
</list></t>
            </li>
          </ul>
        </section>
      </section>
    </section>
    <section anchor="existingCapabilities"><name>Improving existing anchor="existingCapabilities">
      <name>Improving Existing COIN capabilities</name> Capabilities</name>
      <section anchor="CDNs"><name>Content anchor="CDNs">
        <name>Content Delivery Networks</name>
        <section anchor="description-5"><name>Description</name> anchor="description-5">
          <name>Description</name>
          <t>Delivery of content to end users often relies on Content Delivery
          Networks (CDNs).  CDNs store said content closer to end users for
          latency-reduced delivery as well as to reduce load on origin
          servers.  For this, they often utilize DNS-based indirection to
          serve the request on behalf of the origin server.  Both of these
          objectives are within scope to be addressed by COIN methods and
          solutions.</t>
        </section>
        <section anchor="characterization-5"><name>Characterization</name> anchor="characterization-5">
          <name>Characterization</name>
          <t>From the perspective of this draft, a CDN can be interpreted as a
          (network service level) set of (COIN) programs.  These programs
          implement a distributed logic for first distributing content from
          the origin server to the CDN ingress and then further to the CDN
          replication points points, which ultimately serve the user-facing content
          requests.</t>
        </section>
        <section anchor="existing-solutions-5"><name>Existing anchor="existing-solutions-5">
          <name>Existing Solutions</name>
          <t>CDN technologies have been well described and deployed in the
          existing Internet.  Core technologies like Global Server Load
          Balancing (GSLB) <xref target="GSLB"/> and Anycast server solutions
          are used to deal with the required indirection of a content request
          (usually in the form of an HTTP request) to the most suitable local
          CDN server.  Content is replicated from seeding servers, which serve
          as injection points for content from content owners/producers, to
          the actual CDN servers, who which will eventually serve the user's
          request.  The replication architecture and mechanisms itself differs themselves differ
          from one (CDN) provider to another, and often utilizes utilize private
          peering or network arrangements in order to distribute the content
          internationally and regionally.</t>

          <t>Studies such as those in <xref target="FCDN"/> have shown that
          content distribution at the level of named content, utilizing
          efficient (e.g., Layer 2) 2 (L2)) multicast for replication towards edge CDN
          nodes, can significantly increase the overall network and server
          efficiency.  It also reduces indirection latency for content
          retrieval as well as required edge storage capacity by benefiting
          from the increased network efficiency to renew edge content more
          quickly against changing demand.  Works such as those in <xref
          target="SILKROAD"/> utilize ASICs Application-Specific Integrated Circuits (ASICs) to replace server-based load
          balancing with significant cost reductions, thus showcasing the
          potential for in-network CN operations.</t>
        </section>
        <section anchor="opportunities-5"><name>Opportunities</name>

<t><list style="symbols"> anchor="opportunities-5">
          <name>Opportunities</name>
          <ul spacing="normal">
            <li>
              <t>Supporting service-level routing of requests (service (such as service
              routing in <xref target="APPCENTRES"/>) target="I-D.sarathchandra-coin-appcentres"/>)
              to specific (COIN) program instances may improve on end user end-user
              experience in faster retrieving (possibly also more, e.g., faster (and possibly better
              quality) content.</t>
            </li>
            <li>
              <t>COIN instances may also be utilized to integrate
              service-related telemetry information to support the selection
              of the final service instance destination from a pool of
              possible choices</t>
  <t>Supporting choices.</t>
            </li>

<!-- [rfced] Section 5.1.4: To improve readability and avoid overuse
of "e.g.," and parentheses, how may these items be updated?

i) Does "(e.g., virtualized, distributed)" mean the set of choices
are virtualized and/or distributed?

Original:
   *  Supporting the selection of a service destination from a set of
      possible (e.g., virtualized, distributed) choices, e.g., through
      constraint-based routing decisions (see <xref target="APPCENTRES"/>) [APPCENTRES]) in (COIN)
      program instances to improve the overall end user experience by
      selecting a 'more suitable' service destination over another,
      e.g., avoiding/reducing overload situations in specific service destinations.</t>
  <t>Supporting
      destinations.

Option A:
   *  Supporting the selection of a service destination from a set of
      possible choices (virtualized and distributed) in (COIN) program
      instances (e.g., through constraint-based routing decisions as seen in
      [APPCENTRES]) to improve the overall end-user experience by selecting a
      "more suitable" service destination over another (e.g.,
      avoiding/reducing overload situations in specific service destinations).

Option B (moving the last two examples to one final sentence):
   *  Supporting the selection of a service destination from a set of
      possible choices (virtualized and distributed) in (COIN) program
      instances to improve the overall end-user experience by selecting a
      "more suitable" service destination over another. (For example,
      selecting through constraint-based routing decisions as seen in
      [APPCENTRES] may allow avoiding/reducing overload situations in
      specific service destinations.)

ii) Does "in-network/switch-based" mean "in-network and switch-based"?

Original:
   *  Supporting Layer 2 capabilities for multicast (compute
      interconnection and collective communication in [APPCENTRES]),
      e.g., through in-network/switch-based replication decisions (and
      their optimizations) based on dynamic group membership
      information, may reduce the network utilization and therefore
      increase the overall system efficiency.

Perhaps (moving the example to the end):
   *  Supporting L2 capabilities for multicast (compute interconnection
      and collective communication as seen in [APPCENTRES]) may
      reduce the network utilization and therefore increase the overall
      system efficiency. For example, this support may be
      through in-network, switch-based replication decisions (and their
      optimizations) based on dynamic group membership information.
-->

<li>
              <t>Supporting the selection of a service destination from a set
              of possible (e.g., virtualized, distributed) choices, e.g.,
              through constraint-based routing decisions (see <xref
              target="I-D.sarathchandra-coin-appcentres"/>) in (COIN) program
              instances to improve the overall end-user experience by
              selecting a "more suitable" service destination over another,
              e.g., avoiding/reducing overload situations in specific service
              destinations.</t>
            </li>
            <li>
              <t>Supporting L2 capabilities for multicast (compute
              interconnection and collective communication in <xref target="APPCENTRES"/>),
              target="I-D.sarathchandra-coin-appcentres"/>), e.g., through
              in-network/switch-based replication decisions (and their
              optimizations) based on dynamic group membership information,
              may reduce the network utilization and therefore increase the
              overall system efficiency.</t>
</list></t>
            </li>
          </ul>
        </section>
        <section anchor="research-questions-4"><name>Research anchor="research-questions-4">
          <name>Research Questions</name>
          <t>In addition to the research questions in <xref target="mobileOffloadRQ"/>:</t>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>RQ 5.1.1: How to utilize L2 multicast to improve on CDN
              designs? How to utilize COIN capabilities in those designs, such
              as through on-path optimizations for fanouts?</t>
            </li>
            <li>
              <t>RQ 5.1.2: What forwarding methods may support the required
              multicast capabilities (see <xref target="FCDN"/>) and how could
              programmable COIN forwarding elements support those methods
              (e.g., extending current SDN capabilities)?</t>
            </li>
            <li>
              <t>RQ 5.1.3: What are the constraints, reflecting both compute
              and network capabilities, that may support joint optimization of
              routing and computing? How could intermediary (COIN) program
              instances support, e.g., for example, the aggregation of those constraints to
              reduce overall telemetry network traffic?</t>
            </li>
            <li>
              <t>RQ 5.1.4: Could traffic steering be performed on the data
              path and per service request, e.g., request (e.g., through (COIN) program
              instances that perform novel routing request lookup methods? methods)? If
              so, what would be performance improvements?</t>
            </li>
            <li>
              <t>RQ 5.1.5: How could storage be traded off against frequent,
              multicast-based replication (see <xref target="FCDN"/>)? Could
              intermediary/in-network (COIN) elements support the storage
              beyond current endpoint-based methods?</t>
            </li>
            <li>
              <t>RQ 5.1.6: What scalability limits exist for L2 multicast
              capabilities? How to overcome them, e.g., through (COIN) program
              instances serving as stateful subtree aggregators to reduce the
              needed identifier space for, e.g., (e.g., for bit-based forwarding?</t>
</list></t> forwarding)?</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="CFaaS"><name>Compute-Fabric-as-a-Service anchor="CFaaS">
        <name>Compute-Fabric-as-a-Service (CFaaS)</name>
        <section anchor="description-6"><name>Description</name>

<t>We anchor="description-6">
          <name>Description</name>

<!-- [rfced] FYI - We have added a subject for "such as exposed through" in
the text below. Also, we assumed "InfiBand" was intended as "InfiniBand".
Please review.

Original:
   We interpret connected compute resources as operating at a suitable
   layer, such as Ethernet, InfiBand but also at Layer 3, to allow for
   the exchange of suitable invocation methods, such as exposed through
   verb-based or socket-based APIs.

Current:
   We interpret connected compute resources as operating at a suitable
   layer, such as Ethernet, InfiniBand, but also at Layer 3 (L3), to allow
   for the exchange of suitable invocation methods, such as those
   exposed through verb-based or socket-based APIs.
-->

          <t>We interpret connected compute resources as operating at a
          suitable layer, such as Ethernet, InfiniBand, but also at Layer 3 (L3), to
          allow for the exchange of suitable invocation methods, such as those
          exposed through verb-based or socket-based APIs.  The specific
          invocations here are subject to the applications running over a
          selected pool of such connected compute resources.</t>
          <t>Providing such a pool of connected compute resources, e.g., resources (e.g., in
          regional or edge data centers, base stations, and even end user devices, end-user
          devices) opens up the opportunity for infrastructure providers to
          offer CFaaS-like offerings to application providers, leaving the
          choice of the appropriate invocation method to the app and service
          provider.  Through this, the compute resources can be utilized to
          execute the desired (COIN) programs of which the application is
          composed, while utilizing the interconnection between those compute
          resources to do so in a distributed manner.</t>
        </section>

        <section anchor="characterization-6"><name>Characterization</name> anchor="characterization-6">
          <name>Characterization</name>
          <t>We foresee those CFaaS offerings to be tenant-specific, with a tenant
          here defined as the provider of at least one application.  For this,
          we foresee an interaction between the CFaaS provider and tenant to
          dynamically select the appropriate resources to define the demand
          side of the fabric.  Conversely, we also foresee the supply side of
          the fabric to be highly dynamic dynamic, with resources being offered to the
          fabric through, e.g., for example, user-provided resources (whose supply might
          depend on highly context-specific supply policies) or infrastructure
          resources of intermittent availability such as those provided
          through road-side infrastructure in vehicular scenarios.</t>
          <t>The resulting dynamic demand-supply matching establishes a
          dynamic nature of the compute fabric that in turn requires trust
          relationships to be built dynamically between the resource
          provider(s) and the CFaaS provider.  This also requires the
          communication resources to be dynamically adjusted to suitably
          interconnect all resources into the (tenant-specific) fabric exposed
          as CFaaS.</t>
        </section>
        <section anchor="existing-solutions-6"><name>Existing anchor="existing-solutions-6">
          <name>Existing Solutions</name>
          <t>There exist a number of technologies to build non-local (wide
          area) Layer 2 L2 as well as Layer 3 L3 networks, which in turn allows for connecting
          compute resources for a distributed computational task.  For
          instance, 5G-LAN <xref target="SA2-5GLAN"/> specifies a cellular L2
          bearer for interconnecting L2 resources within a single cellular
          operator.  The work in <xref target="ICN5GLAN"/>
          target="I-D.trossen-icnrg-ip-icn-5glan"/> outlines using a
          path-based forwarding solution over 5G-LAN as well as SDN-based LAN
          connectivity together with an ICN-based Information-Centric Network (ICN)
          based naming of IP and HTTP-level resources resources. This is done in order
          to achieve computational interconnections, including scenarios such
          as those outlined in <xref target="mobileAppOffload"/>.  L2 network
          virtualization (see, e.g., (see <xref target="L2Virt"/>) is one of the methods
          used for realizing so-called 'cloud-native' "cloud-native" applications for
          applications developed with 'physical' "physical" networks in mind, thus
          forming an interconnected compute and storage fabric.</t>
        </section>
        <section anchor="opportunities-6"><name>Opportunities</name>

<t><list style="symbols"> anchor="opportunities-6">
          <name>Opportunities</name>
          <ul spacing="normal">
            <li>
              <t>Supporting service-level routing of compute resource requests (service
              (such as service routing in <xref target="APPCENTRES"/>)
              target="I-D.sarathchandra-coin-appcentres"/>) may allow for
              utilizing the wealth of compute resources in the overall CFaaS
              fabric for execution of distributed applications, where the
              distributed constituents of those applications are realized as
              (COIN) programs and executed within a COIN system as (COIN)
              program instances.</t>
            </li>
            <li>
              <t>Supporting the constraint-based selection of a specific
              (COIN) program instance over others (constraint-based (such as constraint-based routing in
              <xref target="APPCENTRES"/>) target="I-D.sarathchandra-coin-appcentres"/>) will allow
              for optimizing both the CFaaS provider constraints as well as
              tenant-specific constraints.</t>
            </li>
            <li>
              <t>Supporting Layer 2 L2 and 3 L3 capabilities for multicast (compute (such as compute
              interconnection and collective communication in <xref target="APPCENTRES"/>)
              target="I-D.sarathchandra-coin-appcentres"/>) will allow for
              decreasing both network utilization but also possible compute
              utilization (due to avoiding unicast replication at those
              compute endpoints), thereby decreasing total cost of ownership
              for the CFaaS offering.</t>
            </li>

<!-- [rfced] Section 5.2.4. Opportunities: How may we add a verb/outcome
to the second part of this list item, in order to be consistent with the
rest of the items in this section?

Original:
   *  Supporting the enforcement of trust relationships and isolation
      policies through intermediary (COIN) program instances, e.g.,
      enforcing specific traffic shares or strict isolation of traffic
      through differentiated queueing.

Perhaps:
   *  Supporting the enforcement of trust relationships and isolation
      policies through intermediary (COIN) program instances (e.g.,
      enforcing specific traffic shares or strict isolation of traffic
      through differentiated queueing) will allow for [what?].
-->

            <li>
              <t>Supporting the enforcement of trust relationships and
              isolation policies through intermediary (COIN) program
              instances, e.g., enforcing specific traffic shares or strict
              isolation of traffic through differentiated queueing.</t>
</list></t>
            </li>
          </ul>
        </section>
        <section anchor="research-questions-5"><name>Research anchor="research-questions-5">
          <name>Research Questions</name>
          <t>In addition to the research questions in <xref
          target="mobileOffloadRQ"/>:</t>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>RQ 5.2.1: How to convey tenant-specific requirements for the
              creation of the CFaaS fabric?</t>
            </li>
            <li>
              <t>RQ 5.2.2: How to dynamically integrate resources into the
              compute fabric being utilized for the app execution (those
              resources include, but are not limited to, end user end-user provided
              resources), particularly when driven by tenant-level
              requirements and changing service-specific constraints? How can
              those resources be exposed through possible (COIN) execution
              environments?</t>
            </li>
            <li>
              <t>RQ 5.2.3: How to utilize COIN capabilities to aid the
              availability and accountability of resources, i.e., what may be
              (COIN) programs for a CFaaS environment that in turn would
              utilize the distributed execution capability of a COIN
              system?</t>
            </li>
            <li>
              <t>RQ 5.2.4: How to utilize COIN capabilities to enforce traffic
              and isolation policies for establishing trust between tenant and
              CFaaS provider in an assured operation?</t>
            </li>
            <li>
              <t>RQ 5.2.5: How to optimize the interconnection of compute
              resources, including those dynamically added and removed during
              the provisioning of the tenant-specific compute fabric?</t>
</list></t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="virtNetProg"><name>Virtual anchor="virtNetProg">
        <name>Virtual Networks Programming</name>
        <section anchor="description-7"><name>Description</name> anchor="description-7">
          <name>Description</name>
          <t>The term "virtual network programming" is proposed to describe
          mechanisms by which tenants deploy and operate COIN programs in
          their virtual network.  Such COIN programs can, e.g., be can be, for example, P4
          programs, OpenFlow rules, or higher layer programs.  This feature
          can enable other use cases described in this draft to be deployed
          using virtual networks network services, over underlying networks such as datacenters,
          data centers, mobile networks, or other fixed or wireless
          networks.</t>
          <t>For example, COIN programs could perform the following on a
          tenant's virtual network:</t>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>Allow or block flows, and request rules from an SDN
              controller for each new flow, or for flows to or from specific
              hosts that need enhanced security</t> security.</t>
            </li>
            <li>
              <t>Forward a copy of some flows towards a node for storage and analysis</t>
              analysis.</t>
            </li>
            <li>
              <t>Update metrics based on specific sources/destinations or
              protocols, for detailed analytics</t> analytics.</t>
            </li>
            <li>
              <t>Associate traffic between specific endpoints, using specific
              protocols, or originated from a given application, to a given
              slice, while other traffic uses a default slice</t> slice.</t>
            </li>
            <li>
              <t>Experiment with a new routing protocol (e.g., ICN), using a
              P4 implementation of a router for this protocol</t>
</list></t> protocol.</t>
            </li>
          </ul>
        </section>
        <section anchor="characterization-7"><name>Characterization</name> anchor="characterization-7">
          <name>Characterization</name>
          <t>To provide a concrete example of virtual COIN programming, we
          consider a use case using a 5G underlying network, the 5GLAN
          virtualization technology, and the P4 programming language and
          environment.  As an assumption in this use case, some mobile network
          equipment (e.g., UPF) User Plane Functions (UPFs)) and devices (e.g.,
          mobile phones or residential gateways) include a network switch
          functionality that is used as a PND.</t>

<t>Section 5.1 of <xref target="I-D.ravi-icnrg-5gc-icn"/>
          <t><xref target="I-D.ravi-icnrg-5gc-icn" sectionFormat="of"
          section="5.1"/> provides a description of the 5G network functions
          and interfaces relevant to 5GLAN, which are otherwise specified in
          <xref target="TS23.501"/> and <xref target="TS23.502"/>.  From the
          5GLAN service customer/tenant standpoint, the 5G network operates as
          a switch.</t>
          <t>In the use case depicted in <xref target="figureVN1"/>, the
          tenant operates a network including a 5GLAN network segment (seen as
          a single logical switch), as well as fixed segments.  The mobile
          devices (or User Equipment nodes) UE1, UE2, UE3 UE3, and UE4 are in
          the same 5GLAN, as well as Device1 and Device2 (through UE4).  This
          scenario can take place in a plant or enterprise network, using, e.g., using a 5G Non-Public Network.
          non-public network, for example.  The tenant uses P4 programs to
          determine the operation of both the fixed and 5GLAN switches.  The
          tenant provisions a 5GLAN P4 program into the mobile network, network and
          can also operate a controller.</t>
          <figure title="5G anchor="figureVN1">
            <name>5G Virtual Network Programming Overview" anchor="figureVN1"><artwork><![CDATA[ Overview</name>
            <artwork><![CDATA[
                                     ..... Tenant ........
                          P4 program :                   :
                          deployment :         Operation :
                                     V                   :
  +-----+  air interface +----------------+              :
  | UE1 +----------------+                |              :
  +-----+                |                |              :
                         |                |              :
  +-----+                |                |              V
  | UE2 +----------------+     5GLAN      |      +------------+
  +-----+                |    Logical     +------+ Controller |
                         |     Switch     |  P4  +-------+----+
  +-----+                |                |  runtime     |
  | UE3 +----------------+                |  API         |
  +-----+                |                |              |
                         |                |              |
  +-----+                |                |              |
+-+ UE4 +----------------+                |              |
| +-----+                +----------------+              |
|                                                        |
| Fixed or wireless connection                           |
|                                    P4 runtime API      |
|  +---------+           +-------------------------------+
+--+ Device1 |           |
|  +---------+           |
|                        |
|  +---------+    +------+-----+
`--+ Device2 +----+ P4 Switch  +--->(fixed network)
   +---------+    +------------+
]]></artwork></figure>
]]></artwork>
          </figure>
        </section>
        <section anchor="existing-solutions-7"><name>Existing anchor="existing-solutions-7">
          <name>Existing Solutions</name>
          <t>Research has been conducted, for example by <xref
          target="Stoyanov"/>, to enable P4 network programming of individual
          virtual switches.  To our knowledge, no complete solution has been
          developed for deploying virtual COIN programs over mobile or datacenter
          data center networks.</t>
        </section>
        <section anchor="opportunities-7"><name>Opportunities</name> anchor="opportunities-7">
          <name>Opportunities</name>
          <t>Virtual network programming by tenants could bring benefits such as:</t>

<t><list style="symbols">
          <ul spacing="normal">

<!-- [rfced] May "controller" be plural here in order to be parallel
with the other plural list items?

Original:
   Virtual network programming by tenants could bring benefits such as:

   *  A unified programming model, which can facilitate porting COIN
      programs between data centers, 5G networks, and other fixed and
      wireless networks, as well as sharing controller, code and
      expertise.

Perhaps:
   Virtual network programming by tenants could bring benefits such as:

   *  A unified programming model, which can facilitate porting COIN
      programs between data centers, 5G networks, and other fixed and
      wireless networks, as well as sharing controllers, code, and
      expertise.
-->

            <li>
              <t>A unified programming model, which can facilitate porting
              COIN programs between data centers, 5G networks, and other fixed
              and wireless networks, as well as sharing controller, code and
              expertise.</t>
            </li>
            <li>
              <t>Increasing the level of customization available to
              customers/tenants of mobile networks or datacenters data centers compared to
              typical configuration capabilities.  For example, 5G network
              evolution points to an ever increasing ever-increasing specialization and
              customization of private mobile networks, which could be handled
              by tenants using a programming model similar to P4.</t>
            </li>
            <li>
              <t>Using network programs to influence underlying network services, e.g., request
              services (e.g., requesting specific QoS for some flows in 5G or datacenters,
              data centers) to increase the level of in-depth customization
              available to tenants.</t>
</list></t>
            </li>
          </ul>
        </section>
        <section anchor="research-questions-6"><name>Research anchor="research-questions-6">
          <name>Research Questions</name>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>RQ 5.3.1: Underlying Network Awareness: a network awareness</t>
	      <t>A virtual COIN program can be able to both influence, and be
	      influenced by, the underling network. Research challenges
	      include defining methods to distribute COIN programs, including
	      in a mobile network context, based on network awareness, since
	      some information and actions may be available on some nodes but
	      not on others.</t>
            </li>
            <li>
              <t>RQ 5.3.2: Splitting/Distribution: a Splitting/distribution</t>
	      <t>A virtual COIN program may need to be deployed across
	      multiple computing nodes, leading to research questions around
	      instance placement and distribution. For example, program logic
	      should be applied exactly once or at least once per packet (or
	      at least once for idempotent operations), while allowing an optimal
	      forwarding path by the underlying network. Research challenges
	      include defining manual (by the programmer) or automatic methods
	      to distribute COIN programs that use a low or minimal amount of
	      resources. Distributed P4 programs are studied in <xref
	      target="I-D.hsingh-coinrg-reqs-p4comp"/> and <xref
	      target="Sultana"/> (based on capability 5.3.2).</t>
            </li>
            <li>
              <t>RQ 5.3.3: Multi-Tenancy Support: A Multi-tenancy support</t>
	      <t>A COIN system supporting virtualization should enable tenants
	      to deploy COIN programs onto their virtual networks, in such a
	      way that multiple virtual COIN program instances can run on the
	      same compute node. While mechanisms were proposed for P4
	      multi-tenancy in a switch <xref target="Stoyanov"/>, research
	      questions remain about isolation between tenants and fair
	      repartition of resources (based on capability 5.3.3).</t>
            </li>
            <li>
              <t>RQ 5.3.4: Security: how Security</t>
	      <t>How can tenants and underlying networks
              be protected against security risks, including overuse or misuse
              of network resources, injection of traffic, or access to
              unauthorized traffic?</t>
            </li>
            <li>
              <t>RQ 5.3.5: Higher layer processing: can processing</t>
	      <t>Can a virtual network model facilitate the deployment of COIN
	      programs acting on application layer application-layer data? This is an open question
	      question, since the present this section focused focuses on packet/flow
	      processing.</t>
</list></t>
            </li>
          </ul>
        </section>
      </section>
    </section>

    <section anchor="newCapabilities"><name>Enabling new anchor="newCapabilities">
      <name>Enabling New COIN capabilities</name> Capabilities</name>

      <section anchor="distributedAI"><name>Distributed anchor="distributedAI">
        <name>Distributed AI Training</name>
        <section anchor="description-8"><name>Description</name> anchor="description-8">
          <name>Description</name>
          <t>There is a growing range of use cases demanding the realization
          of AI training capabilities among distributed endpoints.  One such
          use case is to distribute large-scale model training across more
          than one data center, e.g., center (e.g., when facing energy issues at a single
          site or when simply reaching the scale of training capabilities at
          one site, thus wanting to complement training with the capabilities of another,
          another or possibly many sites. sites).  From a COIN perspective, those
          capabilities may be realized as (COIN) programs and executed
          throughout a COIN system, including in PNDs.</t>
        </section>

        <section anchor="characterization-8"><name>Characterization</name> anchor="characterization-8">
          <name>Characterization</name>
          <t>Some solutions may desire the localization of reasoning logic, e.g., logic
          (e.g., for deriving attributes that better preserve privacy of the
          utilized raw input data. data).  Quickly establishing (COIN) program
          instances in nearby compute resources, including PNDs, may even
          satisfy such localization demands on-the-fly on the fly (e.g., when a
          particular use is being realized, then terminated after a given
          time).</t>

          <t>Individual training 'sites' "sites" may not be a data center, but may instead
          consist of powerful, yet stand-along devices, devices that federate
          computing power towards training a model, captured as 'federated training' "federated
          training" and provided through platforms such as <xref
          target="FLOWER"/>.  Use cases here may be that of distributed
          training on (user) image data, the training over federated social
          media sites <xref target="MASTODON"/>, or others.</t>
          <t>Apart from the distribution of compute power, the distribution of
          data may be a driver for distributed AI training use cases, such as
          in the Mastodon federated social media sits sites <xref
          target="MASTODON"/> or training over locally governed patient data
          or others.</t>
        </section>

        <section anchor="existing-solutions-8"><name>Existing anchor="existing-solutions-8">
          <name>Existing Solutions</name>
          <t>Reasoning frameworks, such as TensorFlow, may be utilized for the
          realization of the (distributed) AI training logic, building on
          remote service invocation through protocols such as gRPC <xref
          target="GRPC"/> or MPI the Message Passing Interface (MPI) <xref
          target="MPI"/> with the intention of providing an on-chip NPU (neural processor unit) Neural
          Processor Unit (NPU) like abstraction to the AI framework.</t>
          <t>A number of activities on distributed AI training exist in the
          area of developing the 5th and 6th generation mobile network network, with
          various activities in the 3GPP SDO Standards Development Organization
          (SDO) as well as use cases developed for the ETSI MEC initiative
          mentioned in previous use cases.</t>
        </section>
        <section anchor="opportunities-8"><name>Opportunities</name>

<t><list style="symbols">
  <t>Supporting anchor="opportunities-8">

<!-- [rfced] Section 6.1.4. Opportunities: We are having a difficult time
parsing the two items below. How may we revise for clarity?
(For example, in the second item, please consider where the first "e.g."
phrase end, and how the second "e.g." connects to the preceding text.)

Original:
   *  Supporting service-level routing of training requests (service
      routing in [APPCENTRES]), with AI services being exposed to the
      network, where (COIN) program instances may support the selection
      of the most suitable service instance based on control plane
      information, e.g., on AI worker compute capabilities, being
      distributed across (COIN) program instances.

   *  Supporting the collective communication primitives, such as all-
      to-all, scatter-gather, utilized by the (distributed) AI workers
      to increase the overall network efficiency, e.g., through avoiding
      endpoint-based replication or even directly performing, e.g.,
      reduce, collective primitive operations in (COIN) program
      instances placed in topologically advantageous places.

Perhaps:
   *  Supporting service-level routing of training requests (such as service
      routing in [APPCENTRES]) with AI services being exposed to the
      network, and where (COIN) program instances may support the selection
      of the most suitable service instance based on control plane
      information (e.g., on AI worker compute capabilities being
      distributed across (COIN) program instances).

   *  Supporting the collective communication primitives, such as all-
      to-all and scatter-gather, utilized by the (distributed) AI
      workers may increase the overall network efficiency (e.g.,
      through avoiding endpoint-based replication or even directly
      performing (or reducing) collective primitive operations) in (COIN)
      program instances placed in topologically advantageous places.
-->

          <name>Opportunities</name>
          <ul spacing="normal">
            <li>
              <t>Supporting service-level routing of training requests (such
              as service routing in <xref target="APPCENTRES"/>), target="I-D.sarathchandra-coin-appcentres"/>), with AI services
              being exposed to the network, where (COIN) program instances may
              support the selection of the most suitable service instance
              based on control plane information, e.g., on AI worker compute
              capabilities, being distributed across (COIN) program
              instances.</t>
            </li>
            <li>
              <t>Supporting the collective communication primitives, such as
              all-to-all, scatter-gather, utilized by the (distributed) AI
              workers to increase the overall network efficiency, e.g.,
              through avoiding endpoint-based replication or even directly
              performing, e.g., reduce, collective primitive operations in
              (COIN) program instances placed in topologically advantageous
              places.</t>
            </li>
            <li>
              <t>Supporting collective communication between multiple
              instances of AI services, i.e., services (i.e., (COIN) program instances, instances) may
              positively impact network but also compute utilization by moving
              from unicast replication to network-assisted multicast
              operation.</t>
</list></t>
            </li>
          </ul>
        </section>
        <section anchor="research-questions-7"><name>Research anchor="research-questions-7">
          <name>Research Questions</name>
          <t>In addition to the research questions in <xref
          target="mobileOffloadRQ"/>:</t>

<t><list style="symbols">
          <ul spacing="normal">

<!-- [rfced] Please clarify the final phrase; what is the subject of
"reduce"?  In other words, what educe in a central (COIN) program

Original:
   *  RQ 6.1.1: What are the communication patterns that may be
      supported by collective communication solutions, where those
      solutions directly utilize (COIN) program instance capabilities
      within the network (e.g., reduce in a central (COIN) program
      instance)?
-->
            <li>
              <t>RQ 6.1.1: What are the communication patterns that may be
              supported by collective communication solutions, where those
              solutions directly utilize (COIN) program instance capabilities
              within the network (e.g., reduce in a central (COIN) program
              instance)?</t>
            </li>
            <li>
              <t>RQ 6.1.2: How to achieve scalable collective communication
              primitives with rapidly changing receiver sets, e.g., sets (e.g., where
              training workers may be dynamically selected based on energy
              efficiency constraints <xref target="GREENAI"/>?</t> target="GREENAI"/>)?</t>
            </li>
            <li>
              <t>RQ 6.1.3: What COIN capabilities may support the collective
              communication patterns found in distributed AI problems?</t>
            </li>
            <li>
              <t>RQ 6.1.4: How to support AI-specific invocation protocols,
              such as MPI or RDMA?</t> Remote Direct Memory Access (RDMA)?</t>
            </li>
            <li>
              <t>RQ 6.1.5: What are the constraints for placing (AI) execution
              logic in the form of (COIN) programs in certain logical
              execution points (and their associated physical locations),
              including PNDs, and how to signal and act upon them?</t>
</list></t>
            </li>
          </ul>
        </section>
      </section>
    </section>
    <section anchor="preliminary-categorization-of-the-research-questions"><name>Preliminary anchor="preliminary-categorization-of-the-research-questions">
      <name>Preliminary Categorization of the Research Questions</name>
      <t>This section describes a preliminary categorization of the reseach questions, research
      questions illustrated in <xref target="figureRQCategories"/>.  A more
      comprehensive analysis has been initiated by members of the COINRG
      community in <xref target="USECASEANALYSIS"/> target="I-D.irtf-coinrg-use-case-analysis"/> but has
      not been completed at the time of writing this memo.</t>
      <figure title="Research anchor="figureRQCategories">
        <name>Research Questions Categories" anchor="figureRQCategories"><artwork><![CDATA[ Categories</name>
        <artwork><![CDATA[
   +--------------------------------------------------------------+
   +                       Applicability Areas                    +
   + .............................................................+
   + Transport |   App  |    Data    |  Routing &  | (Industrial) +
   +           | Design | Processing | Forwarding  |    Control   +
   +--------------------------------------------------------------+

   +--------------------------------------------------------------+
   +    Distributed Computing FRAMEWORKS and LANGUAGES to COIN    +
   +--------------------------------------------------------------+

   +--------------------------------------------------------------+
   +                ENABLING TECHNOLOGIES for COIN                +
   +--------------------------------------------------------------+

   +--------------------------------------------------------------+
   +                      VISION(S) for COIN                      +
   +--------------------------------------------------------------+
]]></artwork></figure>
]]></artwork>
      </figure>

<!-- [rfced] Section 7:

a) In Figure 4 (and throughout Section 7) some words are in all caps, while
others are not. Should these partially capitalized phrases be updated to match
the other categories that appear in title case?

Partially capitalized:
   VISION(S) for COIN
   ENABLING TECHNOLOGIES for COIN
   Distributed Computing FRAMEWORKS and LANGUAGES to COIN

Title case:
   Applicability Areas
   Transport
   App Design
   Data Processing
   Routing & Forwarding
   (Industrial) Control

b) FYI - We have replaced the asterisks in this section with quotation marks
to indicate that these terms refer to items in Figure 4.
-->

      <t>The *VISION(S) "VISION(S) for COIN* COIN" category is about defining and shaping the
      exact scope of COIN.  In contrast to the ENABLING TECHNOLOGIES "ENABLING TECHNOLOGIES" category,
      these research questions look at the problem from a more philosophical
      perspective.  In particular, the questions center around where to
      perform computations, which tasks are suitable for COIN, for which tasks
      COIN is suitable, and which forms of deploying COIN might be desirable.
      This category includes the research questions 3.1.8, 3.2.1, 3.3.5,
      3.3.6, 3.3.7, 5.3.3, 6.1.1, and 6.1.3.</t>
      <t>The *ENABLING "ENABLING TECHNOLOGIES for COIN* COIN" category digs into what
      technologies are needed to enable COIN, which of the existing
      technologies can be reused for COIN, and what might be needed to make
      the VISION(S) "VISION(S) for COIN COIN" a reality.  In contrast to the VISION(S), "VISION(S) for COIN", these
      research questions look at the problem from a practical perspective, e.g., perspective
      (e.g., by considering how COIN can be incorporated in existing systems or
      how the interoperability of COIN execution environments can be enhanced. enhanced).
      This category includes the research questions 3.1.7, 3.1.8, 3.2.3,
      4.2.7, 5.1.1, 5.1.2, 5.1.6, 5.3.1, 6.1.2, and 6.1.3.</t>
      <t>The *Distributed "Distributed Computing FRAMEWORKS and LANGUAGES to COIN* COIN" category
      focuses on how COIN programs can be deployed and orchestrated.  Central
      questions arise regarding the composition of COIN programs, the
      placement of COIN functions, the (dynamic) operation and integration of
      COIN systems as well as additional COIN system properties.  Notably,
      COIN diversifies general distributed computing platforms such that many
      COIN-related research questions could also apply to general distributed
      computing frameworks.  This category includes the research questions
      3.1.1, 3.2.4, 3.3.1, 3.3.2, 3.3.3, 3.3.5, 4.1.1, 4.1.4, 4.1.5, 4.1.8,
      4.2.1, 4.2.4, 4.2.5, 4.2.6, 4.3.3, 5.2.1, 5.2.2, 5.2.3, 5.2.5, 5.3.1,
      5.3.2, 5.3.3, 5.3.4, 5.3.5, and 6.1.5.</t>
      <t>In addition to these core categories, there are use-case-specific use case specific
      research questions that are heavily influenced by the specific
      constraints and objectives of the respective use cases.  This *Applicability Areas*
      "Applicability Areas" category can be further refined into the following
      subgroups:</t>

<t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>The *Transport* "Transport" subgroup addresses the need to adapt transport
          protocols to handle dynamic deployment locations effectively.  This
          subgroup includes the research question 3.1.2.</t>
        </li>
        <li>
          <t>The *App Design* "App Design" subgroup relates to the design principles and
          considerations when developing COIN applications.  This subgroup
          includes the research questions 4.1.2, 4.1.3, 4.1.7, 4.2.6, 5.1.1,
          5.1.3, and 5.1.5.</t>
        </li>
        <li>
          <t>The *Data Processing* "Data Processing" subgroup relates to the handling, storage,
          analysis, and processing of data in COIN environments.  This
          subgroup includes the research questions 3.2.4, 3.2.6, 4.2.2, 4.2.3,
          and 4.3.2.</t>
        </li>
        <li>
          <t>The *Routing "Routing &amp; Forwarding* Forwarding" subgroup explores efficient
          routing and forwarding mechanisms in COIN, considering factors such
          as network topology, congestion control, and quality of service.
          This subgroup includes the research questions 3.1.2, 3.1.3, 3.1.4,
          3.1.5, 3.1.6, 3.2.6, 5.1.2, 5.1.3, 5.1.4, and 6.1.4.</t>
        </li>
        <li>
          <t>The *(Industrial) Control* "(Industrial) Control" subgroup relates to industrial control
          systems, addressing issues like real-time control, automation, and
          fault tolerance.  This subgroup includes the research questions
          3.1.9, 3.2.5, 3.3.1, 3.3.4, 4.1.1, 4.1.6, 4.1.8, 4.2.3, 4.3.1, and
          4.3.4.</t>
</list></t>
        </li>
      </ul>
    </section>
    <section anchor="sec_considerations"><name>Security anchor="sec_considerations">
      <name>Security Considerations</name>
      <t>COIN systems, like any other system using ``middleboxes'', "middleboxes", can have
      different security and privacy implications that strongly depend on the
      used platforms, the provided functionality, and the deployment domain,
      with most if not all considerations for general middleboxes also
      applying for to COIN systems.</t>
      <t>One critical aspect for early COIN systems is the use of early-generation early
      generation PNDs, many of which do not have cryptography support and only
      have limited computational capabilities.  Hence, PND-based COIN systems
      typically work on unencrypted data and often customize packet payload payload,
      while concepts, concepts such as homomorphic encryption, encryption could serve as
      workarounds, allowing PNDs to perform simple operations on the encrypted
      data without having access to it.  All these approaches introduce the
      same or very similar security implications as any middlebox operating on
      unencrypted traffic or having access to encryption: a middlebox can
      itself have malicious intentions, e.g., intentions (e.g., because it got compromised, compromised or
      the deployment of functionality offers new attack vectors to outsiders.</t>
      outsiders).</t>
      <t>However, similar to middlebox deployments, risks for privacy and of data
      exposure have to be carefully considered in the context of the concrete
      deployment.  For example, exposing data to an external operator for
      mobile application offloading leads to a significant privacy loss of the
      user in any case.  In contrast, such privacy considerations are not as
      relevant for COIN systems where all involved entities are under the same
      control, such as in an industrial context.  Here, exposed data and
      functionality can instead lead to stolen business secrets or the
      enabling of, e.g., of DoS attacks. attacks, for example.  Hence, even in fully controlled
      scenarios, COIN intermediaries, and middleboxes in general, are ideally
      operated in a least-privilege mode, where they have exactly those
      permissions to read and alter payload that are necessary to fulfil fulfill their
      purpose.</t>
      <t>Research on granting middleboxes access to secured traffic is only in
      its infancy infancy, and a variety of different approaches are proposed and
      analyzed <xref target="TLSSURVEY"/>.  In a SplitTLS <xref
      target="SPLITTLS"/> deployment, e.g., for example, middleboxes have different
      incoming and outgoing TLS channels, such that they have full read and
      write access to all intercepted traffic.  More restrictive approaches
      for deploying middleboxes rely on searchable encryption or
      zero-knowledge proofs to expose less data to intermediaries, but those
      only offer limited functionality.
MADTLS<xref  MADTLS <xref target="MADTLS"/> is
      tailored to the industrial domain and offers bit-level read and write
      access to intermediaries with low latency and bandwidth overhead, at the
      cost of more complex key management.  Overall, different proposals offer
      different advantages and disadvantages that must be carefully considered
      in the context of concrete deployments.  Further research could pave the
      way for a more unified and configurable solution that is easier to
      maintain and deploy.</t>
      <t>Finally, COIN systems and other middlebox deployments can also lead
      to security risks even if the attack stems from an outsider without
      direct access to any devices.  As such, metadata about the entailed
      processing (processing times, times or changes in incoming and outgoing data) can
      allow an attacker to extract valuable information about the process.
      Moreover, such deployments can become central entities that, if
      paralyzed (e.g., through extensive requests), can be responsible for
      large-scale outages.  In particular, some deployments could be used to
      amplify DoS attacks.  Similar to other middlebox deployments, these
      potential risks must be considered when deploying COIN functionality and
      may influence the selection of suitable security protocols.</t>
      <t>Additional system-level security considerations may arise from
      regulatory requirements imposed on COIN systems overall, stemming from
      regulation regarding, e.g., lawful interception, data localization, or
      AI use. use, for example.  These requirements may impact, e.g., for example, the manner in which (COIN)
      programs may be placed or executed in the overall system, who can invoke
      certain (COIN) programs in what PND or COIN device, and what type of
      (COIN) program can be run.  These considerations will impact the design
      of the possible implementing protocols but also the policies that govern
      the execution of (COIN) programs.</t>
    </section>

    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>
<t>N/A</t>
      <t>This document has no IANA actions.</t>
    </section>

    <section anchor="conclusion"><name>Conclusion</name> anchor="conclusion">
      <name>Conclusion</name>
      <t>This document presented presents use cases gathered from several application
      domains that can and could profit from capabilities that are provided by
      in-network and, more generally, distributed compute platforms.  We distinguished
      distinguish between use cases in which COIN may enable new experiences
      (<xref target="newExperiences"/>), expose new features (<xref
      target="newCapabilities"/>), or improve on existing system capabilities
      (<xref target="existingCapabilities"/>), and other use cases where COIN
      capabilities enable totally new applications, for example, in industrial
      networking (<xref target="newEnvironments"/>).</t>
      <t>Beyond the mere description and characterization of those use cases,
      we identified identify opportunities arising from utilizing COIN capabilities and formulated
      formulate corresponding research questions that may need to be
      addressed before being able to reap those opportunities.</t>
      <t>We acknowledge that this work offers no comprehensive overview of
      possible use cases and is thus only a snapshot of what may be possible
      if COIN capabilities existed.<br /> existed.  In fact, the decomposition of many
      current client-server applications into node by node node-by-node transit could
      identify other opportunities for adding computing to forwarding forwarding, notably
      in supply-chain, the supply chain, health care, intelligent cities and transportation transportation,
      and even financial services (among others).  The presented use cases were
      are selected based on the expertise of the contributing community
      members at the time of writing and are intended to cover a diverse range range,
      from immersive and interactive media, industrial networks, to AI with
      varying characteristics, thus, providing the basis for a thorough
      subsequent analysis.</t>
    </section>
<section anchor="acknowledgements"><name>Acknowledgements</name>

<t>The authors would like to thank Eric Wagner for providing text on the security considerations and Jungha Hong for her efforts in continuing the work on the use case analysis document that has largely sourced the preliminary categorization section of this document.
The authors would further like to thank Chathura Sarathchandra, David Oran, Phil Eardley, Stuart Card, Jeffrey He, Toerless Eckert, and Jon Crowcroft for reviewing earlier versions of the document, Colin Perkins for his IRTF chair review, and Jerome Francois for his thorough IRSG review.</t>

</section>

  </middle>

  <back>

    <references title='Informative References'>

<reference anchor='APPCENTRES'>
   <front>
      <title>In-Network Computing for App-Centric Micro-Services</title>
      <author fullname='Dirk Trossen' initials='D.' surname='Trossen'>
         <organization>Huawei</organization>
      </author>
      <author fullname='Chathura Sarathchandra' initials='C.' surname='Sarathchandra'>
         <organization>InterDigital Inc.</organization>
      </author>
      <author fullname='Michael Boniface' initials='M.' surname='Boniface'>
         <organization>University of Southampton</organization>
      </author>
      <date day='26' month='January' year='2021'/>
      <abstract>
	 <t>   The application-centric deployment of &#x27;Internet&#x27; services has
   increased over the past ten years with many millions of applications
   providing user-centric services, executed on increasingly more
   powerful smartphones that are supported by Internet-based cloud
   services in distributed data centres, the latter mainly provided by
   large scale players such as Google, Amazon and alike. This draft
   outlines a vision for evolving those data centres towards executing
   app-centric micro-services; we dub this evolved data centre
    <displayreference target="I-D.trossen-icnrg-ip-icn-5glan" to="ICN-5GLAN"/>
    <displayreference target="I-D.sarathchandra-coin-appcentres" to="APPCENTRES"/>
    <displayreference target="I-D.irtf-coinrg-use-case-analysis" to="USE-CASE-AN"/>
    <displayreference target="I-D.hsingh-coinrg-reqs-p4comp" to="P4-SPLIT"/>
    <displayreference target="I-D.ravi-icnrg-5gc-icn" to="ICN-5GC"/>
    <references>
      <name>Informative References</name>

<!-- [APPCENTRES]
draft-sarathchandra-coin-appcentres-04
IESG State: Expired as an
   AppCentre. Complemented with the proliferation of such AppCentres at
   the edge of the network, they will allow for such micro-services to
   be distributed across many places of execution, including mobile
   terminals themselves, while specific micro-service chains equal
   today&#x27;s applications in existing smartphones.

   We outline the key enabling technologies that needs to be provided
   for such evolution to be realized, including references 03/21/25.
-->
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.sarathchandra-coin-appcentres.xml"/>

<!-- [RUETH] anchor changed to ongoing
   standardization efforts in key areas.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-sarathchandra-coin-appcentres-04'/>

</reference> match surname Rüth.
-->
      <reference anchor='RUETH'> anchor="RÜTH">
        <front>
          <title>Towards In-Network Industrial Feedback Control</title>
          <author fullname='Jan Rueth' initials='J.' surname='Rueth'> fullname="Jan Rüth" initials="J." surname="Rüth">
            <organization>RWTH Aachen University</organization>
          </author>
          <author fullname='Rene Glebke' initials='R.' surname='Glebke'> fullname="René Glebke" initials="R." surname="Glebke">
            <organization>RWTH Aachen University</organization>
          </author>
          <author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'> fullname="Klaus Wehrle" initials="K." surname="Wehrle">
            <organization>RWTH Aachen University</organization>
          </author>
          <author fullname='Vedad Causevic' initials='V.' surname='Causevic'> fullname="Vedad Causevic" initials="V." surname="Causevic">
            <organization>Technical University of Munich</organization>
          </author>
          <author fullname='Sandra Hirche' initials='S.' surname='Hirche'> fullname="Sandra Hirche" initials="S." surname="Hirche">
            <organization>Technical University of Munich</organization>
          </author>
          <date month='August' year='2018'/> month="August" year="2018"/>
        </front>
  <seriesInfo name='Proceedings
        <refcontent>Proceedings of the 2018 Morning Workshop on In-Network' value='Computing'/> In-Network Computing, pp. 14-19</refcontent>
        <seriesInfo name='DOI' value='10.1145/3229591.3229592'/> name="DOI" value="10.1145/3229591.3229592"/>
      </reference>

<!-- [VESTIN] -->
      <reference anchor='VESTIN'> anchor="VESTIN">
        <front>
          <title>FastReact: In-Network Control and Caching for Industrial Control Networks using Programmable Data Planes</title>
          <author fullname='Jonathan Vestin' initials='J.' surname='Vestin'> fullname="Jonathan Vestin" initials="J." surname="Vestin">
            <organization/>
          </author>
          <author fullname='Andreas Kassler' initials='A.' surname='Kassler'> fullname="Andreas Kassler" initials="A." surname="Kassler">
            <organization/>
          </author>
          <author fullname='Johan Akerberg' initials='J.' surname='Akerberg'> fullname="Johan Akerberg" initials="J." surname="Akerberg">
            <organization/>
          </author>
          <date month='September' year='2018'/> month="September" year="2018"/>
        </front>
  <seriesInfo name='2018
        <refcontent>2018 IEEE 23rd International Conference on Emerging Technologies and Factory Automation (ETFA)' value='pp. 219-226'/> (ETFA), pp. 219-226</refcontent>
        <seriesInfo name='DOI' value='10.1109/etfa.2018.8502456'/> name="DOI" value="10.1109/etfa.2018.8502456"/>
      </reference>

<!-- [GLEBKE] -->
      <reference anchor='GLEBKE'> anchor="GLEBKE">
        <front>
          <title>A Case for Integrated Data Processing in Large-Scale Cyber-Physical Systems</title>
          <author fullname='Rene Glebke' initials='R.' surname='Glebke'> fullname="Rene Glebke" initials="R." surname="Glebke">
            <organization/>
          </author>
          <author fullname='Martin Henze' initials='M.' surname='Henze'> fullname="Martin Henze" initials="M." surname="Henze">
            <organization/>
          </author>
          <author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'> fullname="Klaus Wehrle" initials="K." surname="Wehrle">
            <organization/>
          </author>
          <author fullname='Philipp Niemietz' initials='P.' surname='Niemietz'> fullname="Philipp Niemietz" initials="P." surname="Niemietz">
            <organization/>
          </author>
          <author fullname='Daniel Trauth' initials='D.' surname='Trauth'> fullname="Daniel Trauth" initials="D." surname="Trauth">
            <organization/>
          </author>
          <author fullname='Patrick Mattfeld MBA' initials='P.' surname='Mattfeld MBA'> fullname="Patrick Mattfeld" initials="P." surname="Mattfeld">
            <organization/>
          </author>
          <author fullname='Thomas Bergs' initials='T.' surname='Bergs'> fullname="Thomas Bergs" initials="T." surname="Bergs">
            <organization/>
          </author>
          <date year='2019'/> year="2019"/>
        </front>
  <seriesInfo name='Proceedings
        <refcontent>Proceedings of the Annual Hawaii International Conference on System' value='Sciences'/> System Sciences</refcontent>
        <seriesInfo name='DOI' value='10.24251/hicss.2019.871'/> name="DOI" value="10.24251/hicss.2019.871"/>
      </reference>

<reference anchor='USECASEANALYSIS'>
   <front>
      <title>Use Case Analysis for Computing in the Network</title>
      <author fullname='Ike Kunze' initials='I.' surname='Kunze'>
         <organization>RWTH Aachen University</organization>
      </author>
      <author fullname='Jungha Hong' initials='J.' surname='Hong'>
         <organization>ETRI</organization>
      </author>
      <author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'>
         <organization>RWTH Aachen University</organization>
      </author>
      <author fullname='Dirk Trossen' initials='D.' surname='Trossen'>
         <organization>Huawei Technologies Duesseldorf GmbH</organization>
      </author>
      <author fullname='Marie-Jose Montpetit' initials='M.' surname='Montpetit'>
         <organization>Concordia University</organization>
      </author>
      <author fullname='Xavier de Foy' initials='X.' surname='de Foy'>
         <organization>InterDigital Communications, LLC</organization>
      </author>
      <author fullname='David Griffin' initials='D.' surname='Griffin'>
         <organization>University College London</organization>
      </author>
      <author fullname='Miguel Rio' initials='M.' surname='Rio'>
         <organization>University College London</organization>
      </author>
      <date day='4' month='December' year='2024'/>
      <abstract>
	 <t>   Computing in the Network (COIN) has the potential to enable a wide
   variety of use cases.  The diversity in use cases makes challenges in
   defining general considerations.  This document analyzes the use
   cases described in a COINRG companion document and potentially
   explores additional settings, to identify general aspects

<!-- draft-irtf-coinrg-use-case-analysis-02
IESG State: I-D Exists as of interest
   across all use cases.  The insights gained from this analysis will
   guide future COIN discussions.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-irtf-coinrg-use-case-analysis-02'/>

</reference> 03/21/25.
-->
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.irtf-coinrg-use-case-analysis.xml"/>

<!-- [P4] -->
      <reference anchor='P4'> anchor="P4">
        <front>
          <title>P4: programming protocol-independent packet processors</title>
          <author fullname='Pat Bosshart' initials='P.' surname='Bosshart'> fullname="Pat Bosshart" initials="P." surname="Bosshart">
            <organization>Barefoot Networks, Palo Alto, CA, USA</organization>
          </author>
          <author fullname='Dan Daly' initials='D.' surname='Daly'> fullname="Dan Daly" initials="D." surname="Daly">
            <organization>Intel, Ann Arbor, MI, USA</organization>
          </author>
          <author fullname='Glen Gibb' initials='G.' surname='Gibb'> fullname="Glen Gibb" initials="G." surname="Gibb">
            <organization>Barefoot Networks, Palo Alto, CA, USA</organization>
          </author>
          <author fullname='Martin Izzard' initials='M.' surname='Izzard'> fullname="Martin Izzard" initials="M." surname="Izzard">
            <organization>Barefoot Networks, Palo Alto, CA, USA</organization>
          </author>
          <author fullname='Nick McKeown' initials='N.' surname='McKeown'> fullname="Nick McKeown" initials="N." surname="McKeown">
            <organization>Stanford University, Stanford, CA, USA</organization>
          </author>
          <author fullname='Jennifer Rexford' initials='J.' surname='Rexford'> fullname="Jennifer Rexford" initials="J." surname="Rexford">
            <organization>Princeton University, Princeton, NJ, USA</organization>
          </author>
          <author fullname='Cole Schlesinger' initials='C.' surname='Schlesinger'> fullname="Cole Schlesinger" initials="C." surname="Schlesinger">
            <organization>Princeton University, Princeton, NJ, USA</organization>
          </author>
          <author fullname='Dan Talayco' initials='D.' surname='Talayco'> fullname="Dan Talayco" initials="D." surname="Talayco">
            <organization>Barefoot Networks, Palo Alto, CA, USA</organization>
          </author>
          <author fullname='Amin Vahdat' initials='A.' surname='Vahdat'> fullname="Amin Vahdat" initials="A." surname="Vahdat">
            <organization>Google, Mountain View, CA, USA</organization>
          </author>
          <author fullname='George Varghese' initials='G.' surname='Varghese'> fullname="George Varghese" initials="G." surname="Varghese">
            <organization>Microsoft Research, Mountain View, CA, USA</organization>
          </author>
          <author fullname='David Walker' initials='D.' surname='Walker'> fullname="David Walker" initials="D." surname="Walker">
            <organization>Princeton University, Princeton, NJ, USA</organization>
          </author>
          <date month='July' year='2014'/> month="July" year="2014"/>
        </front>
  <seriesInfo name='ACM
        <refcontent>ACM SIGCOMM Computer Communication Review' value='vol. Review, vol. 44, no. 3, pp. 87-95'/> 87-95</refcontent>
        <seriesInfo name='DOI' value='10.1145/2656877.2656890'/> name="DOI" value="10.1145/2656877.2656890"/>
      </reference>

<!-- [GRPC] -->
      <reference anchor="GRPC" target="https://grpc.io/">
        <front>
          <title>High performance performance, open source universal RPC framework</title>
    <author >
      <organization></organization>
          <author>
            <organization/>
          </author>
    <date />
          <date/>
        </front>
      </reference>

<!-- [MPI] -->
      <reference anchor="MPI" target="https://arxiv.org/pdf/1603.02339.pdf">
        <front>
          <title>Scaling Distributed Machine Learning with In-Network Aggregation</title>
          <author initials="A." surname="Vishnu">
      <organization></organization>
            <organization/>
          </author>
          <author initials="C." surname="Siegel">
      <organization></organization>
            <organization/>
          </author>
          <author initials="J." surname="Daily">
      <organization></organization>
            <organization/>
          </author>
          <date /> month="August" year="2017"/>
        </front>
        <refcontent>arXiv:1603.02339v2</refcontent>
      </reference>

<!-- [FCDN] -->
      <reference anchor="FCDN" target="https://arxiv.org/pdf/1803.00876.pdf">
        <front>
    <title>A
          <title>fCDN: A Flexible and Efficient CDN Infrastructure without DNS Redirection of Content Reflection</title>
          <author initials="M." surname="Al-Naday">
      <organization></organization>
            <organization/>
          </author>
          <author initials="M. J." surname="Reed">
      <organization></organization>
            <organization/>
          </author>
          <author initials="J." surname="Riihijarvi">
      <organization></organization>
            <organization/>
          </author>
          <author initials="D." surname="Trossen">
      <organization></organization>
            <organization/>
          </author>
          <author initials="N." surname="Thomos">
      <organization></organization>
            <organization/>
          </author>
          <author initials="M." surname="Al-Khalidi">
      <organization></organization>
            <organization/>
          </author>
    <date />
          <date/>
        </front>
        <refcontent>arXiv:1803.00876v2</refcontent>
      </reference>

<reference anchor='I-D.ravi-icnrg-5gc-icn'>
   <front>
      <title>Enabling ICN in 3GPP&#x27;s 5G NextGen Core Architecture</title>
      <author fullname='Ravi Ravindran' initials='R.' surname='Ravindran'>
         <organization>Futurewei Technologies</organization>
      </author>
      <author fullname='Prakash Suthar' initials='P.' surname='Suthar'>
         <organization>Cisco Systems</organization>
      </author>
      <author fullname='Dirk Trossen' initials='D.' surname='Trossen'>
         <organization>InterDigital Inc.</organization>
      </author>
      <author fullname='Chonggang Wang' initials='C.' surname='Wang'>
         <organization>InterDigital Inc.</organization>
      </author>
      <author fullname='Greg White' initials='G.' surname='White'>
         <organization>CableLabs</organization>
      </author>
      <date day='31' month='May' year='2019'/>
      <abstract>
	 <t>   The proposed 3GPP&#x27;s 5G core nextgen architecture (5GC) offers
   flexibility

<!-- [I-D.ravi-icnrg-5gc-icn]
draft-ravi-icnrg-5gc-icn-04
IESG State: Replaced by draft-irtf-icnrg-5gc-icn
-->
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ravi-icnrg-5gc-icn.xml"/>

<!-- [I-D.hsingh-coinrg-reqs-p4comp]
draft-hsingh-coinrg-reqs-p4comp-03
IESG State: Expired as of 03/21/25.
-->
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.hsingh-coinrg-reqs-p4comp.xml"/>

<!--[rfced] References:

a) For [Stoyanov], would you like to introduce new user and control plane function,
   considering change the support URL for network slicing functions, that allows
   greater flexibility to handle heterogeneous devices and applications.
   In this draft, we provide a short description of the proposed 5GC
   architecture, including recent efforts to provide cellular Local Area
   Network (LAN) connectivity, followed by extensions to 5GC&#x27;s control
   and user plane to support Packet Data Unit (PDU) sessions from
   Information-Centric Networks (ICN).  In addition, ICN over 5GLAN is
   also described.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ravi-icnrg-5gc-icn-04'/>

</reference>

<reference anchor='I-D.hsingh-coinrg-reqs-p4comp'>
   <front>
      <title>Requirements for P4 Program Splitting for Heterogeneous Network Nodes</title>
      <author fullname='Hemant Singh' initials='H.' surname='Singh'>
         <organization>MNK Labs and Consulting</organization>
      </author>
      <author fullname='Marie-Jose Montpetit' initials='M.' surname='Montpetit'>
         <organization>Concordia Univeristy</organization>
      </author>
      <date day='18' month='February' year='2021'/>
      <abstract>
	 <t>
reference or leave it as is?

Current: https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf
Perhaps: https://dl.acm.org/doi/10.1145/3426744.3431329

b) For distributed computing, [SA2-5GLAN], the P4 research community has published URL provided returns a
   paper "403 - Forbidden"
error. We were unable to show find an alternative source for this
reference. Please review and let us know how to split a P4 program into sub-programs which run
   on heterogeneous network nodes in a network.  Examples update.

Current:
   [SA2-5GLAN]
              3GPP-5glan, "SP-181129, Work Item Description,
              Vertical_LAN(SA2), 5GS Enhanced Support of nodes are a
   network switch, a smartNIC, or a host machine.  The paper has
   developed artifacts to split program based on latency, data rate,
   cost, etc.  However, the paper does not mention any requirements.  To
   provide guidance, this document covers requirements for splitting P4
   programs for heterogeneous network nodes.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-hsingh-coinrg-reqs-p4comp-03'/>

</reference> Vertical and
              LAN Services", 3GPP , 2021,
              <http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-
              181120.zip>.
-->

      <reference anchor="Stoyanov" target="https://eng.ox.ac.uk/media/6354/stoyanov2020mtpsa.pdf">
        <front>
          <title>MTPSA: Multi-Tenant Programmable Switches</title>
          <author initials="R." surname="Stoyanov">
      <organization></organization>
            <organization/>
          </author>
          <author initials="N." surname="Zilberman">
      <organization></organization>
            <organization/>
          </author>
          <date month="December" year="2020"/>
        </front>
        <seriesInfo name="ACM name="DOI" value="10.1145/3426744.3431329"/>
        <refcontent>Proceedings of the 3rd P4 Workshop in Europe (EuroP4'20)" value=""/> Europe, pp. 43-48</refcontent>
      </reference>

      <reference anchor="TS23.501" target="https://www.3gpp.org/DynaReport/23501.htm">
        <front>
    <title>Technical Specification Group Services and System Aspects; System
          <title>System Architecture for the 5G System; Stage 2 (Rel.17)</title>
    <author initials="" surname="3gpp-23.501" fullname="3gpp-23.501">
      <organization></organization>
          <author>
            <organization>3GPP</organization>
          </author>
          <date year="2021"/>
        </front>
        <seriesInfo name="3GPP" value=""/> value="TS 23.501"/>
      </reference>

      <reference anchor="TS23.502" target="https://www.3gpp.org/DynaReport/23502.htm">
        <front>
    <title>Technical Specification Group Services and System Aspects; Procedures
          <title>Procedures for the 5G System; Stage 2 (Rel.17)</title>
    <author initials="" surname="3gpp-23.502" fullname="3gpp-23.502">
      <organization></organization>
          <author>
            <organization>3GPP</organization>
          </author>
          <date year="2021"/>
        </front>
        <seriesInfo name="3GPP" value=""/> value="TS 23.502"/>
      </reference>

      <reference anchor="SA2-5GLAN" target="http://www.3gpp.org/ftp/tsg_sa/TSG_SA/Docs/SP-181120.zip">
        <front>
          <title>SP-181129, Work Item Description, Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and LAN Services</title>
          <author initials="" surname="3GPP-5glan" fullname="3GPP-5glan">
      <organization></organization>
            <organization/>
          </author>
          <date year="2021"/>
        </front>
        <seriesInfo name="3GPP" value=""/>
      </reference>

<reference anchor='ICN5GLAN'>
   <front>
      <title>IP-based

<!--[rfced] We see that draft-trossen-icnrg-ip-icn-5glan
was replaced by draft-trossen-icnrg-internet-icn-5glan. Would you
like this reference to be updated to the latter?

Current:
   [ICN-5GLAN]
              Trossen, D., Wang, C., Robitzsch, S., Reed, M., AL-Naday,
              M., and J. Riihijarvi, "IP-based Services over ICN in 5G
              LAN Environments</title>
      <author fullname='Dirk Trossen' initials='D.' surname='Trossen'>
         <organization>InterDigital Inc.</organization>
      </author>
      <author fullname='Chonggang Wang' initials='C.' surname='Wang'>
         <organization>InterDigital Inc.</organization>
      </author>
      <author fullname='Sebastian Robitzsch' initials='S.' surname='Robitzsch'>
         <organization>InterDigital Inc.</organization>
      </author>
      <author fullname='Martin Reed' initials='M.' surname='Reed'>
         <organization>Essex University</organization>
      </author>
      <author fullname='Mays AL-Naday' initials='M.' surname='AL-Naday'>
         <organization>Essex University</organization>
      </author>
      <author fullname='Janne Riihijarvi' initials='J.' surname='Riihijarvi'>
         <organization>RWTH Aachen</organization>
      </author>
      <date day='6' month='June' year='2019'/>
      <abstract>
	 <t>   In this draft, we provide architecture and operations for enabling IP
   services over ICN over (5G-enabled) LAN environments.  Operations
   include ICN API to upper layers, HTTP over ICN, Service Proxy
   Operations, ICN Flow Management, Name Resolution, Mobility Handling,
   and Dual Stack Device Support.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-trossen-icnrg-ip-icn-5glan-00'/>

</reference> Environments", Work in Progress, Internet-Draft,
              draft-trossen-icnrg-ip-icn-5glan-00, 6 June 2019,
              <https://datatracker.ietf.org/doc/html/draft-trossen-
              icnrg-ip-icn-5glan-00>.
-->
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.trossen-icnrg-ip-icn-5glan.xml"/>

      <reference anchor="Sultana" target="https://flightplan.cis.upenn.edu/flightplan.pdf">
        <front>
          <title>Flightplan: Dataplane Disaggregation and Placement for P4 Programs</title>
          <author initials="N." surname="Sultana">
      <organization></organization>
            <organization/>
          </author>
          <author initials="J." surname="Sonchack">
      <organization></organization>
            <organization/>
          </author>
          <author initials="H." surname="Giesen">
      <organization></organization>
            <organization/>
          </author>
          <author initials="I." surname="Pedisich">
      <organization></organization>
            <organization/>
          </author>
          <author initials="Z." surname="Han">
      <organization></organization>
            <organization/>
          </author>
          <author initials="N." surname="Shyamkumar">
      <organization></organization>
            <organization/>
          </author>
          <author initials="S." surname="Burad">
      <organization></organization>
            <organization/>
          </author>
          <author initials="A." surname="DeHon">
      <organization></organization>
            <organization/>
          </author>
          <author initials="B. T." surname="Loo">
      <organization></organization>
            <organization/>
          </author>
    <date year="2020"/>
        </front>
      </reference>

<!-- [ETSI] -->
      <reference anchor="ETSI" target="https://www.etsi.org/technologies/multi-access-edge-computing">
        <front>
          <title>Multi-access Edge Computing (MEC)</title>
          <author initials="" surname="ETSI" fullname="ETSI">
      <organization></organization>
            <organization/>
          </author>
    <date year="2022"/>
        </front>
      </reference>

<!-- [Microservices] -->
      <reference anchor="Microservices" target="https://microservices.io/">
        <front>
          <title>What are microservices?</title>
          <author initials="C." surname="Richardson">
      <organization></organization>
            <organization/>
          </author>
    <date year="2024"/>
        </front>
      </reference>

<!-- [GSLB] -->
      <reference anchor="GSLB" target="https://www.cloudflare.com/learning/cdn/glossary/global-server-load-balancing-gslb/">
        <front>
          <title>What is global server load balancing (GSLB)?</title>
    <author initials="" surname="Cloudflare" fullname="Cloudflare">
      <organization></organization>
          <author>
            <organization>Cloudflare</organization>
          </author>
    <date year="2022"/>
        </front>
      </reference>

<!-- [L2Virt] -->
      <reference anchor="L2Virt" target="https://blogs.oracle.com/cloud-infrastructure/post/first-principles-l2-network-virtualization-for-lift-and-shift">
        <front>
          <title>First principles: L2 network virtualization for lift and shift</title>
          <author initials="L." surname="Kreger-Stickles">
      <organization></organization>
            <organization/>
          </author>
          <date year="2022"/> day="9" month="February" year="2021"/>
        </front>
        <refcontent>Oracle Cloud Infrastructure Blog</refcontent>
      </reference>

<!-- [TOSCA] -->
      <reference anchor="TOSCA" target="https://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/os/TOSCA-Simple-Profile-YAML-v1.3-os.pdf">
        <front>
          <title>TOSCA Simple Profile in YAML Version 1.3</title>
          <author initials="" surname="OASIS TOSCA">
      <organization></organization>
    </author> fullname="Matt Rutkowski" role="editor"/>
          <author fullname="Chris Lauwers" role="editor"/>
          <author fullname="Claude Noshpitz" role="editor"/>
          <author fullname="Calin Curescu" role="editor"/>
          <date month="February" year="2020"/>
        </front>
        <refcontent>OASIS Standard</refcontent>
      </reference>

<!-- [FLOWER] -->
      <reference anchor="FLOWER" target="https://flower.ai/">
        <front>
          <title>A Friendly Federated AI Framework</title>
          <author initials="" surname="Flower Labs GmbH">
      <organization></organization>
            <organization/>
          </author>
    <date year="2024"/>
        </front>
      </reference>

<!-- [KUNZE-APPLICABILITY] -->
      <reference anchor='KUNZE-APPLICABILITY'> anchor="KUNZE-APPLICABILITY">
        <front>
          <title>Investigating the Applicability of In-Network Computing to Industrial Scenarios</title>
          <author fullname='Ike Kunze' initials='I.' surname='Kunze'> fullname="Ike Kunze" initials="I." surname="Kunze">
            <organization/>
          </author>
          <author fullname='Rene Glebke' initials='R.' surname='Glebke'> fullname="Rene Glebke" initials="R." surname="Glebke">
            <organization/>
          </author>
          <author fullname='Jan Scheiper' initials='J.' surname='Scheiper'> fullname="Jan Scheiper" initials="J." surname="Scheiper">
            <organization/>
          </author>
          <author fullname='Matthias Bodenbenner' initials='M.' surname='Bodenbenner'> fullname="Matthias Bodenbenner" initials="M." surname="Bodenbenner">
            <organization/>
          </author>
          <author fullname='Robert fullname="Robert H. Schmitt' initials='R.' surname='Schmitt'> Schmitt" initials="R." surname="Schmitt">
            <organization/>
          </author>
          <author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'> fullname="Klaus Wehrle" initials="K." surname="Wehrle">
            <organization/>
          </author>
          <date month='May' year='2021'/> month="May" year="2021"/>
        </front>
  <seriesInfo name='2021
        <refcontent>2021 4th IEEE International Conference on Industrial Cyber-Physical Systems (ICPS)' value='pp. 334-340'/> (ICPS), pp. 334-340</refcontent>
        <seriesInfo name='DOI' value='10.1109/icps49255.2021.9468247'/> name="DOI" value="10.1109/icps49255.2021.9468247"/>
      </reference>

<!-- [KUNZE-SIGNAL] -->
      <reference anchor='KUNZE-SIGNAL'> anchor="KUNZE-SIGNAL">
        <front>
          <title>Detecting Out-Of-Control Sensor Signals in Sheet Metal Forming using In-Network Computing</title>
          <author fullname='Ike Kunze' initials='I.' surname='Kunze'> fullname="Ike Kunze" initials="I." surname="Kunze">
            <organization>Communication and Distributed Systems</organization>
          </author>
          <author fullname='Philipp Niemietz' initials='P.' surname='Niemietz'> fullname="Philipp Niemietz" initials="P." surname="Niemietz">
            <organization>Laboratory for Machine Tools and Production Engineering (WZL)</organization>
          </author>
          <author fullname='Liam Tirpitz' initials='L.' surname='Tirpitz'> fullname="Liam Tirpitz" initials="L." surname="Tirpitz">
            <organization>Communication and Distributed Systems</organization>
          </author>
          <author fullname='Rene Glebke' initials='R.' surname='Glebke'> fullname="Rene Glebke" initials="R." surname="Glebke">
            <organization>Communication and Distributed Systems</organization>
          </author>
          <author fullname='Daniel Trauth' initials='D.' surname='Trauth'> fullname="Daniel Trauth" initials="D." surname="Trauth">
            <organization>Laboratory for Machine Tools and Production Engineering (WZL)</organization>
          </author>
          <author fullname='Thomas Bergs' initials='T.' surname='Bergs'> fullname="Thomas Bergs" initials="T." surname="Bergs">
            <organization>Laboratory for Machine Tools and Production Engineering (WZL)</organization>
          </author>
          <author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'> fullname="Klaus Wehrle" initials="K." surname="Wehrle">
            <organization>Communication and Distributed Systems</organization>
          </author>
          <date month='June' year='2021'/> month="June" year="2021"/>
        </front>
  <seriesInfo name='2021
        <refcontent>2021 IEEE 30th International Symposium on Industrial Electronics (ISIE)' value='pp. 1-6'/> (ISIE), pp. 1-6</refcontent>
        <seriesInfo name='DOI' value='10.1109/isie45552.2021.9576221'/> name="DOI" value="10.1109/isie45552.2021.9576221"/>
      </reference>

<!-- [SarNet2021] -->
      <reference anchor='SarNet2021'> anchor="SarNet2021">
        <front>
          <title>Service-based Forwarding via Programmable Dataplanes</title>
          <author fullname='Rene Glebke' initials='R.' surname='Glebke'> fullname="Rene Glebke" initials="R." surname="Glebke">
            <organization/>
          </author>
          <author fullname='Dirk Trossen' initials='D.' surname='Trossen'> fullname="Dirk Trossen" initials="D." surname="Trossen">
            <organization/>
          </author>
          <author fullname='Ike Kunze' initials='I.' surname='Kunze'> fullname="Ike Kunze" initials="I." surname="Kunze">
            <organization/>
          </author>
          <author fullname='David Lou' initials='D.' surname='Lou'> fullname="David Lou" initials="D." surname="Lou">
            <organization/>
          </author>
          <author fullname='Jan Rueth' initials='J.' surname='Rueth'> fullname="Jan Ruth" initials="J." surname="Ruth">
            <organization/>
          </author>
          <author fullname='Mirko Stoffers' initials='M.' surname='Stoffers'> fullname="Mirko Stoffers" initials="M." surname="Stoffers">
            <organization/>
          </author>
          <author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'> fullname="Klaus Wehrle" initials="K." surname="Wehrle">
            <organization/>
          </author>
          <date month='June' year='2021'/> month="June" year="2021"/>
        </front>
  <seriesInfo name='2021
        <refcontent>2021 IEEE 22nd International Conference on High Performance Switching and Routing (HPSR)' value='pp. 1-8'/> (HPSR), pp. 1-8</refcontent>
        <seriesInfo name='DOI' value='10.1109/hpsr52026.2021.9481814'/> name="DOI" value="10.1109/hpsr52026.2021.9481814"/>
      </reference>

<!--  [Multi2020] -->
      <reference anchor='Multi2020'> anchor="Multi2020">
        <front>
          <title>Routing on Multiple Optimality Criteria</title>
          <author fullname='João fullname="João Luís Sobrinho' initials='J.' surname='Sobrinho'> Sobrinho" initials="J." surname="Sobrinho">
            <organization>Instituto de Telecomunicações, Instituto Superior Tecnico, Universidade de Lisboa</organization>
          </author>
          <author fullname='Miguel fullname="Miguel Alves Ferreira' initials='M.' surname='Ferreira'> Ferreira" initials="M." surname="Ferreira">
            <organization>Instituto de Telecomunicações, Instituto Superior Tecnico, Universidade de Lisboa</organization>
          </author>
          <date month='July' year='2020'/> month="July" year="2020"/>
        </front>
  <seriesInfo name='Proceedings
        <refcontent>Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and protocols for computer communication' value='pp. 211-225'/> communication, pp. 211-225</refcontent>
        <seriesInfo name='DOI' value='10.1145/3387514.3405864'/> name="DOI" value="10.1145/3387514.3405864"/>
      </reference>

<!-- [SILKROAD] -->
      <reference anchor='SILKROAD'> anchor="SILKROAD">
        <front>
          <title>SilkRoad: Making Stateful Layer-4 Load Balancing Fast and Cheap Using Switching ASICs</title>
          <author fullname='Rui Miao' initials='R.' surname='Miao'> fullname="Rui Miao" initials="R." surname="Miao">
            <organization>University of Southern California</organization>
          </author>
          <author fullname='Hongyi Zeng' initials='H.' surname='Zeng'> fullname="Hongyi Zeng" initials="H." surname="Zeng">
            <organization>Facebook</organization>
          </author>
          <author fullname='Changhoon Kim' initials='C.' surname='Kim'> fullname="Changhoon Kim" initials="C." surname="Kim">
            <organization>Barefoot Networks</organization>
          </author>
          <author fullname='Jeongkeun Lee' initials='J.' surname='Lee'> fullname="Jeongkeun Lee" initials="J." surname="Lee">
            <organization>Barefoot Networks</organization>
          </author>
          <author fullname='Minlan Yu' initials='M.' surname='Yu'> fullname="Minlan Yu" initials="M." surname="Yu">
            <organization>Yale University</organization>
          </author>
          <date month='August' year='2017'/> month="August" year="2017"/>
        </front>
  <seriesInfo name='Proceedings
        <refcontent>Proceedings of the Conference of the ACM Special Interest Group on Data Communication' value='pp. 15-28'/> Communication, pp. 15-28</refcontent>
        <seriesInfo name='DOI' value='10.1145/3098822.3098824'/> name="DOI" value="10.1145/3098822.3098824"/>
      </reference>

<!-- [GREENAI] -->
      <reference anchor='GREENAI'> anchor="GREENAI">
        <front>
          <title>A Safe Genetic Algorithm Approach for Energy Efficient Federated Learning in Wireless Communication Networks</title>
          <author fullname='Lina Magoula' initials='L.' surname='Magoula'> fullname="Lina Magoula" initials="L." surname="Magoula">
            <organization>National and Kapodistrian University of Athens,Dept. of Informatics and Telecommunications,Greece</organization>
          </author>
          <author fullname='Nikolaos Koursioumpas' initials='N.' surname='Koursioumpas'> fullname="Nikolaos Koursioumpas" initials="N." surname="Koursioumpas">
            <organization>National and Kapodistrian University of Athens,Dept. of Informatics and Telecommunications,Greece</organization>
          </author>
          <author fullname='Alexandros-Ioannis Thanopoulos' initials='A.' surname='Thanopoulos'> fullname="Alexandros-Ioannis Thanopoulos" initials="A." surname="Thanopoulos">
            <organization>National and Kapodistrian University of Athens,Dept. of Informatics and Telecommunications,Greece</organization>
          </author>
          <author fullname='Theodora Panagea' initials='T.' surname='Panagea'> fullname="Theodora Panagea" initials="T." surname="Panagea">
            <organization>National and Kapodistrian University of Athens,Dept. of Informatics and Telecommunications,Greece</organization>
          </author>
          <author fullname='Nikolaos Petropouleas' initials='N.' surname='Petropouleas'> fullname="Nikolaos Petropouleas" initials="N." surname="Petropouleas">
            <organization>National and Kapodistrian University of Athens,Dept. of Informatics and Telecommunications,Greece</organization>
          </author>
          <author fullname='M. fullname="M. A. Gutierrez-Estevez' initials='M.' surname='Gutierrez-Estevez'> Gutierrez-Estevez" initials="M." surname="Gutierrez-Estevez">
            <organization>Huawei Technologies Duesseldorf GmbH,Munich Research Center,Munich,Germany</organization>
          </author>
          <author fullname='Ramin Khalili' initials='R.' surname='Khalili'> fullname="Ramin Khalili" initials="R." surname="Khalili">
            <organization>Huawei Technologies Duesseldorf GmbH,Munich Research Center,Munich,Germany</organization>
          </author>
          <date month='September' year='2023'/> month="September" year="2023"/>
        </front>
  <seriesInfo name='2023
        <refcontent>2023 IEEE 34th Annual International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC)' value='pp. 1-6'/> (PIMRC), pp. 1-6</refcontent>
        <seriesInfo name='DOI' value='10.1109/pimrc56721.2023.10293863'/> name="DOI" value="10.1109/pimrc56721.2023.10293863"/>
      </reference>

<!-- [TLSSURVEY] -->
      <reference anchor='TLSSURVEY'> anchor="TLSSURVEY">
        <front>
          <title>A Survey and Analysis of TLS Interception Mechanisms and Motivations: Exploring how end-to-end TLS is made "end-to-me" 'end-to-me' for web traffic</title>
          <author fullname='Xavier fullname="Xavier de Carne Carné de Carnavalet' initials='X.' surname='de Carne Carnavalet" initials="X." surname="de Carné de Carnavalet'> Carnavalet">
            <organization>The Hong Kong Polytechnic University, Hong Kong SAR</organization>
          </author>
          <author fullname='Paul fullname="Paul C. van Oorschot' initials='P.' surname='van Oorschot'> Oorschot" initials="P." surname="van Oorschot">
            <organization>Carleton University, Ontario, Canada</organization>
          </author>
          <date month='July' year='2023'/> month="July" year="2023"/>
        </front>
  <seriesInfo name='ACM
        <refcontent>ACM Computing Surveys' value='vol. Surveys, vol. 55, no. 13s, pp. 1-40'/> 1-40</refcontent>
        <seriesInfo name='DOI' value='10.1145/3580522'/> name="DOI" value="10.1145/3580522"/>
      </reference>

<!-- [MADTLS] -->
      <reference anchor='MADTLS'> anchor="MADTLS">
        <front>
          <title>Madtls: Fine-grained Middlebox-aware End-to-end Security for Industrial Communication</title>
          <author fullname='Eric Wagner' initials='E.' surname='Wagner'> fullname="Eric Wagner" initials="E." surname="Wagner">
            <organization/>
          </author>
          <author fullname='David Heye' initials='D.' surname='Heye'> fullname="David Heye" initials="D." surname="Heye">
            <organization/>
          </author>
          <author fullname='Martin Serror' initials='M.' surname='Serror'> fullname="Martin Serror" initials="M." surname="Serror">
            <organization/>
          </author>
          <author fullname='Ike Kunze' initials='I.' surname='Kunze'> fullname="Ike Kunze" initials="I." surname="Kunze">
            <organization/>
          </author>
          <author fullname='Klaus Wehrle' initials='K.' surname='Wehrle'> fullname="Klaus Wehrle" initials="K." surname="Wehrle">
            <organization/>
          </author>
          <author fullname='Martin Henze' initials='M.' surname='Henze'> fullname="Martin Henze" initials="M." surname="Henze">
            <organization/>
          </author>
          <date year='2023'/> year="2023"/>
        </front>
        <seriesInfo name='' value='arXiv'/>
  <seriesInfo name='DOI' value='10.48550/ARXIV.2312.09650'/> name="DOI" value="10.48550/ARXIV.2312.09650"/>
        <refcontent>arXiv:2312.09650</refcontent>
      </reference>

<!-- [SPLITTLS] -->
      <reference anchor='SPLITTLS'> anchor="SPLITTLS">
        <front>
          <title>Multi-Context TLS (mcTLS): Enabling Secure In-Network Functionality in TLS</title>
          <author fullname='David Naylor' initials='D.' surname='Naylor'> fullname="David Naylor" initials="D." surname="Naylor">
            <organization>Carnegie Mellon University, Pittsburgh, PA, USA</organization>
          </author>
          <author fullname='Kyle Schomp' initials='K.' surname='Schomp'> fullname="Kyle Schomp" initials="K." surname="Schomp">
            <organization>Case Western Reserve University, Cleveland, OH, USA</organization>
          </author>
          <author fullname='Matteo Varvello' initials='M.' surname='Varvello'> fullname="Matteo Varvello" initials="M." surname="Varvello">
            <organization>Telefonica Research, Barcelona, Spain</organization>
          </author>
          <author fullname='Ilias Leontiadis' initials='I.' surname='Leontiadis'> fullname="Ilias Leontiadis" initials="I." surname="Leontiadis">
            <organization>Telefonica Research, Barcelona, Spain</organization>
          </author>
          <author fullname='Jeremy Blackburn' initials='J.' surname='Blackburn'> fullname="Jeremy Blackburn" initials="J." surname="Blackburn">
            <organization>Telefonica Research, Barcelona, USA</organization>
          </author>
          <author fullname='Diego fullname="Diego R. Lopez' initials='D.' surname='Lopez'> Lopez" initials="D." surname="Lopez">
            <organization>Telefonica, Barcelona, Spain</organization>
          </author>
          <author fullname='Konstantina Papagiannaki' initials='K.' surname='Papagiannaki'> fullname="Konstantina Papagiannaki" initials="K." surname="Papagiannaki">
            <organization>Telefonica Research, Barcelona, Spain</organization>
          </author>
          <author fullname='Pablo fullname="Pablo Rodriguez Rodriguez' initials='P.' surname='Rodriguez Rodriguez'> Rodriguez" initials="P." surname="Rodriguez Rodriguez">
            <organization>Telefonica Research, Barcelona, Spain</organization>
          </author>
          <author fullname='Peter Steenkiste' initials='P.' surname='Steenkiste'> fullname="Peter Steenkiste" initials="P." surname="Steenkiste">
            <organization>Carnegie Mellon University, Pittsburgh, PA, USA</organization>
          </author>
          <date month='August' year='2015'/> month="August" year="2015"/>
        </front>
  <seriesInfo name='ACM
        <refcontent>ACM SIGCOMM Computer Communication Review' value='vol. Review, vol. 45, no. 4, pp. 199-212'/> 199-212</refcontent>
        <seriesInfo name='DOI' value='10.1145/2829988.2787482'/> name="DOI" value="10.1145/2829988.2787482"/>
      </reference>

<!-- [MASTODON] -->
      <reference anchor='MASTODON'> anchor="MASTODON">
        <front>
          <title>Challenges in the Decentralised Web: The Mastodon Case</title>
          <author fullname='Aravindh Raman' initials='A.' surname='Raman'> fullname="Aravindh Raman" initials="A." surname="Raman">
            <organization>King's College London</organization>
          </author>
          <author fullname='Sagar Joglekar' initials='S.' surname='Joglekar'> fullname="Sagar Joglekar" initials="S." surname="Joglekar">
            <organization>King's College London</organization>
          </author>
          <author fullname='Emiliano fullname="Emiliano De Cristofaro' initials='E.' surname='Cristofaro'> Cristofaro" initials="E." surname="Cristofaro">
            <organization>University College London</organization>
          </author>
          <author fullname='Nishanth Sastry' initials='N.' surname='Sastry'> fullname="Nishanth Sastry" initials="N." surname="Sastry">
            <organization>King's College London</organization>
          </author>
          <author fullname='Gareth Tyson' initials='G.' surname='Tyson'> fullname="Gareth Tyson" initials="G." surname="Tyson">
            <organization>Queen Mary University of London</organization>
          </author>
          <date month='October' year='2019'/> month="October" year="2019"/>
        </front>
  <seriesInfo name='Proceedings
        <refcontent>Proceedings of the Internet Measurement Conference' value='pp. 217-229'/> Conference, pp. 217-229</refcontent>
        <seriesInfo name='DOI' value='10.1145/3355369.3355572'/> name="DOI" value="10.1145/3355369.3355572"/>
      </reference>

<!-- [eCAR] -->
      <reference anchor='eCAR'> anchor="eCAR">
        <front>
          <title>eCAR: edge-assisted Collaborative Augmented Reality Framework</title>
          <author fullname='Jinwoo Jeon' initials='J.' surname='Jeon'> fullname="Jinwoo Jeon" initials="J." surname="Jeon">
            <organization/>
          </author>
          <author fullname='Woontack Woo' initials='W.' surname='Woo'> fullname="Woontack Woo" initials="W." surname="Woo">
            <organization/>
          </author>
          <date year='2024'/> year="2024"/>
        </front>
        <refcontent>arXiv:2405.06872</refcontent>
        <seriesInfo name='arXiv' value='article'/>
  <seriesInfo name='DOI' value='10.48550/ARXIV.2405.06872'/> name="DOI" value="10.48550/ARXIV.2405.06872"/>
      </reference>

<!-- [NetworkedVR] -->
      <reference anchor='NetworkedVR'> anchor="NetworkedVR">
        <front>
          <title>Networked VR: State of the Art, Solutions, and Challenges</title>
          <author fullname='Jinjia Ruan' initials='J.' surname='Ruan'> fullname="Jinjia Ruan" initials="J." surname="Ruan">
            <organization>State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing 100876, China</organization>
          </author>
          <author fullname='Dongliang Xie' initials='D.' surname='Xie'> fullname="Dongliang Xie" initials="D." surname="Xie">
            <organization>State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing 100876, China</organization>
          </author>
          <date month='January' year='2021'/> month="January" year="2021"/>
        </front>
  <seriesInfo name='Electronics' value='vol.
        <refcontent>Electronics, vol. 10, no. 2, pp. 166'/> p. 166</refcontent>
        <seriesInfo name='DOI' value='10.3390/electronics10020166'/> name="DOI" value="10.3390/electronics10020166"/>
      </reference>

<!-- [CompNet2021] -->
      <reference anchor='CompNet2021'> anchor="CompNet2021">
        <front>
          <title>Edge intelligence computing for mobile augmented reality with deep reinforcement learning approach</title>
          <author fullname='Miaojiang Chen' initials='M.' surname='Chen'> fullname="Miaojiang Chen" initials="M." surname="Chen">
            <organization/>
          </author>
          <author fullname='Wei Liu' initials='W.' surname='Liu'> fullname="Wei Liu" initials="W." surname="Liu">
            <organization/>
          </author>
          <author fullname='Tian Wang' initials='T.' surname='Wang'> fullname="Tian Wang" initials="T." surname="Wang">
            <organization/>
          </author>
          <author fullname='Anfeng Liu' initials='A.' surname='Liu'> fullname="Anfeng Liu" initials="A." surname="Liu">
            <organization/>
          </author>
          <author fullname='Zhiwen Zeng' initials='Z.' surname='Zeng'> fullname="Zhiwen Zeng" initials="Z." surname="Zeng">
            <organization/>
          </author>
          <date month='August' year='2021'/> month="August" year="2021"/>
        </front>
        <seriesInfo name='Computer Networks' value='vol. name="DOI" value="10.1016/j.comnet.2021.108186"/>
        <refcontent>Computer Networks, vol. 195, pp. 108186'/>
  <seriesInfo name='DOI' value='10.1016/j.comnet.2021.108186'/> p. 108186</refcontent>
      </reference>

<!-- [WirelessNet2024] -->
      <reference anchor='WirelessNet2024'> anchor="WirelessNet2024">
        <front>
          <title>Online delay optimization for MEC and RIS-assisted wireless VR networks</title>
          <author fullname='Jie Jia' initials='J.' surname='Jia'> fullname="Jie Jia" initials="J." surname="Jia">
            <organization/>
          </author>
          <author fullname='Leyou Yang' initials='L.' surname='Yang'> fullname="Leyou Yang" initials="L." surname="Yang">
            <organization/>
          </author>
          <author fullname='Jian Chen' initials='J.' surname='Chen'> fullname="Jian Chen" initials="J." surname="Chen">
            <organization/>
          </author>
          <author fullname='Lidao Ma' initials='L.' surname='Ma'> fullname="Lidao Ma" initials="L." surname="Ma">
            <organization/>
          </author>
          <author fullname='Xingwei Wang' initials='X.' surname='Wang'> fullname="Xingwei Wang" initials="X." surname="Wang">
            <organization/>
          </author>
          <date month='March' year='2024'/> month="March" year="2024"/>
        </front>
  <seriesInfo name='Wireless Networks' value='vol.
        <refcontent>Wireless Networks, vol. 30, no. 4, pp. 2939-2959'/> 2939-2959</refcontent>
        <seriesInfo name='DOI' value='10.1007/s11276-024-03706-4'/> name="DOI" value="10.1007/s11276-024-03706-4"/>
      </reference>

<reference anchor='RFC7272'>
  <front>
    <title>Inter-Destination Media Synchronization (IDMS) Using

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7272.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8039.xml"/>
    </references>

    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>The authors would like to thank <contact fullname="Eric Wagner"/> for
      providing text on the RTP Control Protocol (RTCP)</title>
    <author fullname='R. van Brandenburg' initials='R.' surname='van Brandenburg'/>
    <author fullname='H. Stokking' initials='H.' surname='Stokking'/>
    <author fullname='O. van Deventer' initials='O.' surname='van Deventer'/>
    <author fullname='F. Boronat' initials='F.' surname='Boronat'/>
    <author fullname='M. Montagud' initials='M.' surname='Montagud'/>
    <author fullname='K. Gross' initials='K.' surname='Gross'/>
    <date month='June' year='2014'/>
    <abstract>
      <t>This document defines a new RTP Control Protocol (RTCP) Packet Type security considerations and an RTCP Extended Report (XR) Block Type <contact
      fullname="Jungha Hong"/> for her efforts in continuing the work on the
      use case analysis document that has largely sourced the preliminary
      categorization section of this document.</t>
      <t>The authors would further like to be used thank <contact fullname="Chathura
      Sarathchandra"/>, <contact fullname="David Oran"/>, <contact
      fullname="Phil Eardley"/>, <contact fullname="Stuart Card"/>, <contact
      fullname="Jeffrey He"/>, <contact fullname="Toerless Eckert"/>, and
      <contact fullname="Jon Crowcroft"/> for achieving Inter-Destination Media Synchronization (IDMS). IDMS is reviewing earlier versions of
      the process document, <contact fullname="Colin Perkins"/> for his IRTF chair
      review, and <contact fullname="Jerome Francois"/> for his thorough IRSG
      review.</t>
    </section>
  </back>

<!-- [rfced] Terminology and Abbreviations:

a) We note different uses of synchronizing playout across multiple media receivers. Using (COIN) and COIN in the RTCP XR IDMS Report Block defined terms below.
For consistency and ease of the reader, we suggest removing the
parentheses in this document, media playout information from participants "(COIN)" when it appears in these instances. Please review
and let us know any objections.

(COIN) execution environment
(COIN) system
(COIN) programs
(COIN) program instances

COIN execution environment
COIN system
COIN programs
COIN program instances

b) In general, is there is a synchronization group can be collected. Based on the collected information, an RTCP IDMS Settings Packet can then be sent to distribute specific meaning that is intended when "COIN"
is in parentheses? If so, could you add a common target playout point sentence to which all define that
meaning? For example, why is COIN in parentheses in this text?

Section 3.1.2:
   However, the distributed receivers, sharing execution of a media experience, can synchronize.</t>
      <t>Typical use cases in which IDMS is useful are social TV, shared service control (i.e., applications where two or (COIN) program may be moved to other
   (e.g., more geographically separated users are watching suitable) devices, including PNDs, which have exposed the
   corresponding (COIN) program as individual (COIN) program instances
   to the (COIN) system by means of a media stream together), distance learning, networked video walls, networked loudspeakers, etc.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='7272'/>
  <seriesInfo name='DOI' value='10.17487/RFC7272'/>
</reference>

<reference anchor='RFC8039'>
  <front>
    <title>Multipath Time Synchronization</title>
    <author fullname='A. Shpiner' initials='A.' surname='Shpiner'/>
    <author fullname='R. Tse' initials='R.' surname='Tse'/>
    <author fullname='C. Schelp' initials='C.' surname='Schelp'/>
    <author fullname='T. Mizrahi' initials='T.' surname='Mizrahi'/>
    <date month='December' year='2016'/>
    <abstract>
      <t>Clock synchronization protocols are very widely 'service identifier'.

We note this convention was also used in IP-based networks. The Network Time Protocol (NTP) has been commonly deployed for many years, and draft-irtf-coinrg-coin-terminology
(now expired), but it does not seem to be explained.

c) How should 'CN' be expanded here?

   Works such as those in [SILKROAD] utilize ASICs to replace server-based
   load balancing with significant cost reductions, thus showcasing the last few years have seen an increasingly rapid deployment of
   potential for in-network CN operations.

d) FYI, we added expansions for the Precision Time Protocol (PTP). As time-sensitive applications evolve, clock accuracy requirements are becoming increasingly stringent, requiring following abbreviations upon first use.
Please review each expansion in the time synchronization protocols to provide high accuracy. This memo describes a multipath approach document carefully to PTP and NTP over IP networks, allowing ensure correctness.

Application-Specific Integrated Circuit (ASIC)
Graphics Processing Units (GPUs)
Information-Centric Network (ICN)
Internet of Things (IoT)
Java Virtual Machine (JVM)
Message Passing Interface (MPI)
Quality of Experience (QoE)
Remote Direct Memory Access (RDMA)
Software-Defined Network (SDN)
Standards Development Organization (SDO)
User Plane Function (UPF)
-->

<!-- [rfced] Please review the protocols to run concurrently over multiple communication paths between "Inclusive Language" portion of the master and slave clocks, without modifying these protocols. The multipath approach can significantly contribute to clock accuracy, security, 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.

a) For example, please consider whether "native" should be updated here:

  so-called 'cloud-native' applications for applications developed

b) In addition, please consider whether instances of "traditional"
and fault tolerance. The multipath approach "traditionally" should be updated for clarity.  While the NIST website
<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1>
indicates that is presented in this document enables backward compatibility with nodes that do term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not support the multipath functionality.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8039'/>
  <seriesInfo name='DOI' value='10.17487/RFC8039'/>
</reference>

    </references>

  </back>

<!-- ##markdown-source:
H4sIAPYgUGcAA8y9e1cbWZYv+D+fIlbmWheolIQNxnZS9143CdhJp40pwM6q
np6pDqSQFGkpQhURAquw57PPfp99QiEyK6t7brtqJSDF4zz22e/92/1+f6vJ
m1l2lHyos+QkrbM6GZdVcl70L7Lmvqw+JSflfLFs8mKyld7eVtndUXLy/vwi
XL81KodFOodHjKp03PTzqhn3h2VeVJP+ss76Q7yo/+TF1iht4KKH0+Obs69b
Q/hjUlaroyQvxuVWvqiOkqZa1s3+kyffP9nfSqssPUreZEVWpbMtHMikKpcL
fvnVm626gQvmR8n51c3rLfgrLUZ/TWdlAW9YwZgW+VHyfzXlsJfUZQWXjmv4
bTXnX2DA83SxgCn931ufqnQ+Ku+Lv5aLJi+L+mgrSeC+v86yu2xWHyVPB4P9
ra102UzL6mirD98mMGL44nyQ/LQs/p7RJzz/80+Z+6ysJkfJ1c83PybH6XCa
FcmHIr/LqjpvVvS9rqa7hD7P5mk+O0o+4YP+ZVjO61U9qO6baT+lawYjfjwu
QNYcJccwsAL+GCSHh/TFEF5w5B84LEcwuNP+4f6TF8/kk2XR4Nq/yap5Wqz8
vH4aJD9n02rmJ/bTLF3W/uN/cm739KT/A5M7HSQ3VVnXcjPP7jQHKvcf0+x+
XKb3WZ7cZMNpUc7KSQ4n43SZwUWzUVmNkzfz2x+jufINfpr44IE8+F/46wHM
OZrhFTyXJrh/eOJm+G5Z5MNpNMOXT77/fr97hn6K7wb/OkjelUWzyOBku2m+
S6s86/9rCec2/pqm+274Jp/NNu0jf+vnNqen/QJPG8z1af8yH07gssEw9TOB
b+GozqJZP3/5JLmeZtVtVZZwaK7p4+TngZvwjwfHycHV03jCJ2mRjtJovn8e
JKMseV2u3FT/nN7lWeU/pzmeF01WneaTvElnyNbmuMgpHfte8vbtSTTE7adP
nkSD/Dmrm+1NE3NjfvOsc8xu7T7T8IDWx+XqX3Ic1IgHRdTRotc3VT4e5xG9
wu2j6HOaXdg6mNtslk2y5G1ZjMoi2skPJ2+jab4p72Glrhs3MXcXT+vnk6dn
yfMfbuJ5ffjJz2k0mPCA/mU5nA3S4WD5qUWWQOqlJ8d8ssxm9uF/gynMaUSD
Ki/9HLZQPsExa2BoKByOLy9Pzi5urs6ugaD6pwMWenVapc10OAUxVKUk/fog
YYYZkggIPySJqw9nNz/C7r0/Hzx9Mnj69Nnh3sH+/veH3z8d8E883B/Prm/O
L9xVT77fO7t5fTzYf/L05eDl4ZP9Z4fP4bo3b89++OnMrtt/tn/4dO/H85Pr
a7zy+8HLF3hyPlyfnRxfnx1fHL/9y/V5NOAuKd0HSp2t6hwGjGO5fBaPdv/5
4fOXL14M6Of3T3AUV5cnR7SEokT8mE+mySKraMWKYZaUCxAOdbms4Pcl7y6c
PbgtGYPgzVCu896KgMXf+0QM9CurDON0VrNcaNJqgls+bZpFfbS3N6kWw0Fe
7sGX7y7Po6FcD9MZSHhgwkAn+e2yyUbAAofTvACiytKqwC/v82bqdZ3jyaTK
JsQS1oYFA5OfQtLHg+RjXk+LZffXJ4PkOgcSnnV/DVz6FMhu1Z4n/tk517T6
nN8NYGn2FqPx3tPnTw4GT/YPDr4fwJ90y+uT04toCY6T17Psc347yxKgy+QM
jucwB5JM4EKYNewALM1y2CyrjFaiXDbJ6cV1cpWN8iob4iok5RiOIrAouOsq
G8/4019fGzjux7P+BTC+1cYLYAWusmy0cXmu8nya/5JWd3n3JS1hvvb9BXw/
Ledl/dgQf5oCmYzy37sLL3EXnrx88Rx3AW7AA1YBf+7nQzxZh5Mh/nYk30xr
ILqpHrsq+1vdXzwDnr/AC66bcpUW5V20hdvvbi6vj1EfmDV5/yYrUtiIy6qc
wOmZp7iz17BzoA3V2x3niOZ5NbBH+49hdf4tn92SBuFmv73/ZP8JP6vOQMTX
yP6AlE7eAT9IfoZDUk/LBTwiOVtWcLqTHfx5+Qzu240WbFtXLCsmg/Izs9O9
OZBWuvf84PDZXi2DwhfO4dIUlxDffHO9fzA4fPI0XghSxEBcz5LrRTbMxyK5
QQ6CWZBcZ0AmQ1DRkNCvV3WTzZPjGi5s6j/a3xWc/iZjekcjp5lmyeEb+Rou
a1IQOPvJzhVIgacvdrtWlGXXwWSx6PMgW0v3dH3pDt5cXnavzP39/QAfReR0
uirSq2wB1sre/gE8eDBt5m419v/TVgOoZ5iNYA3q/6xF2P+vWoR9XYTr4/3+
4Zu3xzF/276+7D99+fTp/vc9oszkHCd6mtXDKidrrpd8zKoGl+mvcO8OPGW3
B5O9Ts6KKYonWJzlAt+GbE4vpUWDy20VH1kCmBWc8dnaCfrNK9BegHGz2Gvq
yV/rdO/m+s1fr4/3TsthvacTfTL4e77AZ5+fXPB6OJHeMDMU1pMv8BceXf8J
Sutr4CEg4eMlfD0Dkd0s4CJULJsUf8tQaKZBFNKKXM7SYTZHOYBUA7xAuNBm
xgMcRl7pPwXGfl0WoCkNP/mPfwRNF9ZKeHnfbOxLYBi1mkLy8b8Nkh/Tov2q
6Sqdf1qCXeK/uB4kPyyrdOQ/A7l9mv1YRg/4AWTFANTGspsVrlHt2JZtMMzr
wRLUnGIAp8p/Iezs7Ob6vMXTiZmnQ6CtOjkbwXkzH0uy8+7s5JFDhw9rDXF/
wxCRrrKmzomuGmfG7s3d+/sZvL8/1Pfjs97lQ6AkIf5o5D9P0yZJgXvO/SWv
NhHACcpw2OlqVJftE/Jsw6ijJ6Nqh9e9uX77Q7yENJK8Tiaz8haOLN4ANsCs
TEcJ/A1nm9YS79t9tXk1T2blcjSewYz+gTUd2k1oru3NRJfcG46KPRhODabA
ao/H1edx9XFcfRtXf1LPbmleb/c/gh7eOpB5VTfJosrh2sUMNgCuSgrRT+/g
8iUoLH/nc4kncZaPGzqg9RR+23gY3w6Sn+A8w2Cugct9ggf/xinfAtHUQEPp
cMYTpvn380h93FuUdbM3xqH3w9D7s/2+jLwfj7wPI+/jyMHkGPVt5Dfvr0+O
W4IOPwJFeg4PRJYzzuEnaB9/OX73Fll2jesAFtTGib8/BsuHn/wbz/YIOO6g
TNEOQvOFz09ZD4El41P6PJi+DKaPI9m7gyHslfXmK/p4Rb+slSu8fvv+57Or
eK6gr4O8KEazVfI6G2VgUYKEOj6HT8VU2jjJ1zOygd+mt3VwTP36YRvTbYM0
J2r86cPFv531wb59e35y/MP52/Obv8SG6PnJ5fWz7/cPDwco4gbfP3v+cv/Z
C7vz+vwNGJqtW67Pz54dHh7uyy2HL57v76PSdJ1WYHThh/ENP15eXx3Cx8/1
HS9B8KH5TEwTd61lQh+8fHH49Nng4NmTw5fP8cLr87c/Xb0/Pm1d9+T7ly/3
9wf88xkZr2dnF8fn8esvz99dnRw+fwGvhncdwOf73x+8fH6AxPn2+vrD1cez
v7QefPjyyeE+qkDvjk/hGvv22cvDwydgL/wZ7IX9g6f7gyffPz8kOQwLfOOv
ZOv65f73MLTB/ouXL5695Odd37w/fX/RnvDh4cHz7wf48/AFXpedHF91vxXW
ZPAEbHa8SkzcbPQxXAzW45O9DI26qgRtsn76BNb36XN0MKBEWtsg+G7vF2QC
cKp5f54+gf3B638GixGOfM33OM/Bkycv9mpQXV4878Pn/ScHL5487z/b2ur3
+wmQawOMpdnaCgIQzjaqpGqR76C/fzeBd4K+SuY6frsAGYHqLOpto2wxK1d4
6wI12xptrGS8LMhSBY7TrBJgEcKH8LtRRsKll9TL4TRJ66QWE4rYqLJa8suN
QedJhijABls/T5H10D3x04dpkdxm8P8iQwM7nfWSvEmm8OCmxC/g/my8nMGp
XqAONcJHlzSNIVrWn2kW+OeEox3sp4Rx4KyDj5JGBw8uwGa2R6P0gQfnI1DM
wAqAh99Ps4rt/Wl5D49Ffy8PrYEJLhaz1WBr62YKshP43JIUukWFihd8XcMq
J8sah4yBIHjHKJuX6IAHVkLPS5NiOQejEYdcw/TJmwA7BMbsjNgVvkGdqrIy
9O5kXJVzunSw9XpZwXSreVllPXzJZAnjT3AQKZhouFt4Ha2iTaxO0PUOv8P6
2JV/W2Y1vwnnWy6bWV7AlSPQuSsyjofpIr3NYZfwAQ3qDBS7qsnYgbtGo0oI
Btc/zHyermidcXQ1mwgw7Bw2fLbq0bVu8co7GCU8DNdxls/hqgqJguJbKqll
h0dkm9zCgzvmgO9iT9l4yT4ZpkO4k3ZrnubFYOuc9B58WTlaDo12Nh6gK30R
m4Y7HD/b1QcVJWoPyfnZzWt7pBCafptQdA0OwYBP7TwfjWbZ1tbWt0ipfA/O
8eHbHP/8CtSVBRq+T3lDJgVSB478Fibcz8ZjtLsWYAZkjR66Hmo09/AmOs30
Vc2EIwtDFAnLVfCqEj/AJUfKmyzTKoW3wlag4cIPgZXIwcbN5xmcEtKSlqT2
wnmEq4YZmYmDLbR8YNOLfLGcpWw5skosf+CdSK706Sz7jEvVlMNy1mIFqJHy
IcbTzpQBGumKdgQkex+OI0zpnliJcpqiJPKBp8M5G+X8NLj/E4wuqVnzIfou
4MNyPIbTlybf1E0p51zW7BtdTGBaSPJwzumY0xPyIfHBcbJYVgtkCUI2Ogbk
VjUc8EIYS73MGzpBqGKmsNBwQO8w5MNPiU458Rq4X95LbACfXaWLHLalKu9h
l+R9gSymrMgx/eBWMVndlp+V0SOHz1FlhOfFy4yDysiEJ0Jx/mYcRzlusiKZ
8emFTYBpwFkfLYl8mCBAeyXPKK9TsrX1IyhCoKn3goipcl6lIrtP1B7pMYeE
T2H4KDsqf6TDSWXWQIwCrqDjisuAgw3s062hHG5hUVX2t2WORhZuMHxSRCfG
nRDQs2dL+g1d3HBw/Uq44wCrBUp7nY3AECHfHbCmil8MKwKXo8tnhEcAFUIQ
decyE5FPQP+zGQ+fyaFBGzeroifBjMyK9IIU/wRmR+e3lp0DyqKreIpjdVKP
1FUfPU8GmtafYB3ROKw95faSbDAZ9GCJViW8dPuXZd1s41FblDmKNByJ+rZ5
YWm9HGk5uusR459mswUuDAYLgCiUccOWREwGn3ybTdO7vKzgTtiMKkuRZu7o
/PvNYAYC5xA4Agm6HCUn87Nxms/QGUdSGQ5ZXsvst/NCraewstv0JFGB+Fqc
D0pjVEzW5R18gpFFmCnK1V9wUaJ1xcfFaoZuFohDpItmCnJjQuvnGQZQxyKt
TPzMcWLEqYE6QBFcTMsiXIxxpXKyWmMCpAgJFYxcnIYHCAR2WwKpJ6lz3IIe
hiuITJBOc1m3pDwwgG0S8v7TbZWKFcb6ihGfQC/HYfl/RkVpJlueNnwEfnU/
TPsDq100EBjxrKTDsqxgXvD4mhglPMRUjB65IGYrmQK9cCffVaFBbAcuhtPy
eYFexGJIO0p7wcpKk8+cdrE25WSHVqliNmir4h63vduDV8I76UDyK716pEdL
34rfk1acDpnx38JqZMBq19VU2UCdDZ4PeBO8Ss8AXjeD8zJawYjympjG2hT4
2Ozkd+tD9JcNtq4zGdGBDfY5XkJalNII62NZvA30Bl1zImQgjySExYhKHE8f
0CGdlKCF5jXLF9KdSTkO/C8wPODq+mg7OnMQ1E2Yd+299ZFkRWaLnJfYZl4U
5R0vMQwxm2fVhJjouhgBWv5hBSxrdsdSghTLOUrbUQ4TXcLgs88p6hUsafFx
6dBkdHqLOxQWDIRipqSdlKQMw27zYePVI40C/lMTG+9QbXH8IExwKURciE6E
ikWlBASS/R6TiRbLeirCBkXdRk7o2ELdsirEblixvddpDpAog5nflbxOdTlj
yVMv0OrTM6W2AkpxUIenyDpuf0GCuzMtSslJlAHOJANS8TIkr9lwGJcqS5v0
c1mUc9IaZRFHouGSRhFtilHs0dbW04EPcnDUvU8Ja0qOkdHRUvlssERuqPVV
SIzoso5us+tUyAFZ7Q+Sk2mKDCBT0+YoOVu/10i6UY/xbYZTZqaFDLJAE0gk
MDCn+wwkZlrLzSA0m3xIJzViOMLEdWQwoIMBvF7PkWwghobD8pAisQQ+CId0
ngEzGMmoUNTLEOL57uQ0CeFMwCTRChrOUjTtJrhB2edpCmoGEMAMH3GXZ/f0
BFiFUQ00Rktto4FRPhsk7/25OUqOi3CixsQ81hk4DrDW+FTlWWc0XFwUIHta
La8AkslA9ArTBvUQB3I4CPagnU7YQTOtnTWqOxeZAmiqC4Pjp7T0JOeIiDgF
huI7OUM6q0tj1fmc4sNN50ldyXnUY9oy3lEbyYdgvlVhae6J9Y/wZJQLstZx
Te0ts5WcRmY7qq02JXGdtKjvQXKJ0dAxdljP54PkeKQm2wZGs0aNabhjXV+b
o2pNFKdmgL0YdCMa/23m3vR71+aPyNTJdMYr2kqUqVacCIK2M9idQxPTPTSe
y0mR/51fgaQCgwgLj7mEdLhqiqnSORGrBi/ctAQk55paziWxFExHTUoeJwpi
2LohmZi1ZKjAaUXX4x1mRsSaINrHomTUS01+gaEMUUUPdvmwBO5QL8B8iCjb
73PsLwNVdbisyUNGS1fnn4F3UXhdND/vJnNSd6NrjTRRy31T0eN1AfXXID8s
RuZKwSgFrdqYpV/CKVwimmWgdNBE0AehaxM16TtozbPKzDMo3kr4o17WOsCr
NwN0At0A98kpuLhKHr4lXvS1vWRLWS1iVXrxKBuTtgxad3kPj4ryWtR/dcre
2mTn8uK03j0yLWrNi7vBccteH/Hw9pzhvnBvU1V3SUfm8lny8HD57OtXZLvM
QoG1g+k3ITNNXNJnn7Mhn7az4i6vygInegSbAqKipjXieAvorva17hU7M0CQ
yCN6bBizUgZqb/KvH9/1YXNhcewa/xy17cBaWxb2vDrsGLsj4ClA5MhOy1G2
tUVExYkeR7QZuKTJDi5QhovEms6umph51f1yVGRKmBiui7lLum1IptcKKKcQ
7gHXznuYFsjRLTiCoILAF7NgLCSUlcJqfKe9QfHrhbtDeCdZt+YjWxOosgAn
+tEKN2ucpSR62MAYRSYWW8suqtDySWy2nU1VEaI0ohESPyKrF44BHsphy7vV
SGzb/IfpEFjUSJQP0pCinB8knTrNR0rR7PMgOhdxgbwXmJmuN9qVgyQ5psmU
wHJMYTNrdpnPGry4rPDYIJNihw3ccZsHXc/NgdZWRuBOiUwYbH70Ig+zowQd
A0C1Bdsm/CmJRb1b9unMLFVcrQ57OLmlrWrQYCHvxG83jpFtXdLy4igu1Ko8
c7b2w7fwSvcBsLRvv03elbfotzx2Rtf78Rjj+/igh2/n9D18LZ/SXd96DUA4
Yz0EiqvyUlccThq6aUlzypG0SE0BeQCK1SSdtyy9noZ59OzQ0oAaviJfY0ph
HN6xjxx4B72PqWvn49VuMgWhWGcNEEFCBq38nbB7us7IhaWxt7Cpr8kM5S1j
a+YbEDH42m9aFwPJFXQwKc3XlCgcZk98v8xY9eHEks0iQJL+eMX+x/gIEm8q
0dtWglVDwjMv4ESy/xJd+rBiIwkagLQi3xwzd1jW23KUA4OAI1moAHFeVBwh
vFUXZ2vrPfnocLu8lS2uL1JgNJqHSgvKR/h0iSNuLR1LYwpUBh6DRJt6I7Mn
dMsbJ+6aDgbc41DAo+svJ3+WjRvlRTIvXX/h2uSnIa2CaA23oI/xkg3r33qN
UG/J1C6+JjisaXW7Cp7ECnnRFF0Qlyfk1IiEb0ukk6Tf1UGzpCirbXT+UsKU
jxVRNKlpMi+pdsZp3ZAmNFKfxCqZglrNOo+qyBynwV93B3xI25YtKCS6zeqt
psMf0QI5V+S8PEoAaGew+AcTqVRZGD2MVLohFj5Y7nX7MTxn85grA1dplEZu
VFsT8uijM1I0DHbx9GBCdUtnJj7cMU/ZZ4tqKt2jMk82f5XB877h8wdz+wb+
CFTzDXvylFjxk4TK+VBQHBcr3XlvkqOYgMmSb1i8Cu3F2DRYUmg+L9ivms2V
+cjtfNYkyNl5aru1HswAyIqOgcD+g3hFVgGcge9F87cI3JmnxxwTTv2QnHEY
BgRBvyqXrbhfnXE6fuwLVJEJz5UpCwMbuOgVhRlt9LQ+3XwB/fV0WJkL7zCH
pMVWe383qNiBRaLGqEr0NL3LZJ1HHYZU68Vp7S2h1pcqVOruvQJeMs/SQnZ8
W5UVczZU2+yXhbeDakieWVwIMDjv0hmpy2WyLatmyndpcnubeYlzYGpIG10q
lFmFVLKcswkvixXuT04uPzgWKnTv1HJiihXYe6JpZdUu0vY4eHVYA28rOLYt
5KCU09N+rjDbeo7hmJuPu7haNSX1UFTVbakloGxcfWW6EsKKdoEjJMgIzKjO
UANpUNSr00T8VeSOW8+UQapWaSxKDYyoQZdVLRoDfqZiJ/uMcSLOuQATfyXk
H1wAlIqYYILpPaZjoqcAT2xNGtI0HAo4Zh2jydGigLNoywTrfpfSFqouqYq2
xrZzb3CimVU1ac4WGagEn8hjDy8t4OVNNiNDScQ+pZPgNmO6bwgUGPNdkWOR
oxyzcih6kGp+wUFalEVfPlUVEjnAw8M4n4Ad4zTPrxTQr1nfDv6U2MuvzwgK
5fbp5RVynm1cH8d00pjtJDu4SzD5yMckKtEpU+rO6W6Pyw3qeueS7cor1tB2
QAmNLIZdIrq2ZsB2O7xCqUaSm5Lr04ueagJ89jH5AQz0VgSFkpVBMUnSuzSf
0TN1b1O3ztukOlNGBZ9PYSidEh8Oy2xmqqD3YjvexLuOlLGtDKEn1pOuGL0e
nx0/k1l/JMjDw9had1YZqC+4o15aronJggW9OXKdsY83sRdg2yl5sgaoGG39
v/Zvy+qnOv9917d/3+mu48Ou6WH+XjGi3L8vevd38Guytf7I7/y1cMkl/7IV
PkzQKJPfOp+abLU//27Txe7KL6dfLr9cfYmvhD+ur9oD+JVn2oca/X781mg1
3b89PzYaRjQ2XYvWv73HX9bxOh3443uR7H2Bkyg1aF/+iv++/FBWwMe/dBDL
d/aAvY436qJ23PglOXxzfAE/97rmuDbUrjfajVuPTSd6vFz5xR7SXlg/Bb34
i/C+L62Lo4XqfLJfna4n+4v3vvx8/vo8Ob4MK8L/bBjwn1P+Za+1Ct/pL+sP
bj0Mvru+6h5sPLfv/ALwNiZfNtBX53zcGy+VE//KTn0RxhJTzM3H9uCiV3tu
9nCUfNsWmpyK/7++8f6d16owOkfPGdtRg2++Aoe8Rn0gyBLHrIflcjbqSfRe
3Sa3WfDskTsOFRbWmPImC+pFykoE28tox5CMBWknXokscSx7e02nq8XVnoox
0gRx5s0RE1ggFDmsvnMNshn0R/ZXx35MugokjNy0q55FynNosnRk+vsC46Ll
sp6tzO+x++iAnaoh6U2xNBL9oAh5E3igTAX4McOwfxz/sQDokAMtuTrgg3os
JnhVLiqKO8aDIp8RBbQwSJuyFq5enJCeB8K3p4ZV2Fp4ta5eOrrD4sKa6+c6
rVnL67L94JVFGzWbjdFOrnn2DacT6UrHehwna7CSXpemDUu8QPRqco6hxrDZ
r6NxRqeEYKqgn7LZI+01Y00N15kc9XsY8etjkLyltPKWpYXzHnmfQTQW9IoE
X59499jrgkaT0emO1BntxtGSUt09qOGaU4i8Fn1L0KLMcsoNUw98gwa/X4O7
PEWrnrdIUi5okkAkTazM31PwKV6xTd46cUBZJsO15g5wTiAW/anS1FUumDw8
4CWo8S/RmY8E5mFrLEXdchJ4dzYaxMSXNE1lXQfmVHU6Q3HEg4wb9atSogQ5
Q5zFqmzC0ga9SaHBZnY0c8oMz/3sRFNHalr/xlJDMNAXCpnlYLOVE/RdHJYN
FNXwEI7C1Kg+RqgRHgJe41V9Zjy1OkzpREWZsHXGrg7One2M7NkxXXtu228T
bdmopBwAmTTXW/Ytq+bhIarRhI3n3IC8oED7jCpeWrWCxOVSKnNRCSMWHB4f
GLtcD48hkAxKV1rWLmk2RQ8yAeu0/PHzDMgccynKBov/yOH8mP/aeJ18y0lq
IK0wLaOijL5jWGteFiIAdg+XmVQkWE4cxc1XBdjDQ7f3nFwUYVisua1nM6LQ
u7Qit0JMIgmCuTAfcF68bvJAzmyDjeiPZuifm+wIJZgTiOzHWSqpRDXGFYeR
r+P04lrjwJLSHN6hfjhbF3SKVCFfhfItWIrraMT9GyKL7Adm259TmEBCDDnD
3paQz4lmv8lhneUhe3Cc3QOJzmYg4YCmRuKmnuWTALJCqW8YCyImrMm3IkEi
8oYFfQvcFJ0+Gw4kWfXLekneUk0r5Joa2b926YWqLxpNCPFlWBx8S1zOaiGq
pUsmYtcD8gCYXVZnktCwsLp4djs752vr1CKDVCdf8N3ehOeSZkO1PTNMVKtS
DrESi3TMObjMbJo6HVZksgYrkOwySt8PRQuS8oRkDXuWVsYZkCUYu81FZ0iF
3tR1tb4d7EeLsvtIPBS+aiPKjORomPJMF6UgaUdgBgm8+uEhYC1hLoaWd/nk
GqsliLinsgbdu3bdBnmubzGVwLw3HHM9LkZVmY/kyHV4zVpbSmq6sIdWeBbf
gyUUqBPMuHKJGZVkQ/HZQtc/ZiYFV3z0hnXXrPN56dNJ4+jKyViiMsOsZAEM
TWblCkicwrLD8WLQqXelZMuyk0bJYgmLPMQTybpdyrUAopL8XFazEaIETTDn
LEGkKtphAqLaYtUmzn8kT9IfkuC2k+SKtueKQkym73c448LdqCSK+5T3SetS
SFfUBNAdfoaGNvoE0AWrHx1bznzrVns4MzCECjrDbUosj8UDLb3SV1Go3339
3QO3ZJH3TyKKWgL7mGffnNne/0fQHugABFL/xBE4wuxaLpi70URzq7oKZm7M
MZPyviBVSXULdoCTXpEVy/A90jml53CCkQag17MP8VuyjMuqjiMl6mNHc7kf
JhVSNfxiRZuyY4nAQgawwqLFt/eHkm8XWAIqKxE9iNJtWmtNAW9cHzMsIyUw
iq1tCq35zGSqG5DoNj2WuRTrC/xMCd515BqQ6qYZw1Elkm6QSHq/VppszKqt
t3HEOYBTN4t/p+U5wMG1WLbPYJYIvKu746xbc/EHs3QDETslRBmRFPUh7t5E
IkePGPqYQ7Th2YQ8yQYp7YMfeXuewYpCM4kfDwtqawSHGJUaLuvE3BDUuSRr
DweBqjMKaJcEOyvLT0BncXyKAvqoF5jBqiOibA74eiZ7giKEyieUOJCwBtlA
Kw6M4UukQApFRVP0FbWSh8W+G7byeYlT3UAmiOCl0HpZlBmSFzuSdBdXGPnw
EAAfvn71ROfCX1q00SI+NiTUIUWpxcECsE2J3SYuhTm6fT2WjeSUjSn8p8sc
2XhWctRK0qMyWX6Y1n52CY1N5ytQqojlyHRIA7PedBjIHUaHoaZYXPy0jWey
R1HBoWoCTO1rG7RLByCscrtSUyqVAveNRr9JCMli37ZWWHjcPMu8Sy48W/NT
SXH2Zo24Tayi4U9WVaCJeOKyvfrTV9mGqz8lB4Ong6dHyY+IjlBKSC5rkVxL
xCr+ipNvjEsTX9dgCh+w1frhgb7G1dZEDn6w8q11Oul5XYbLVHoJepbmXKiw
sGxFzoSghIVwR6yWBp3AnLheUSkUCsQFon2my6torfZtrSgvQm3EnJQKLJ5i
8l/bdJe4y/blJkpmmYnXkacPeXmWwC4PP81WrxA+ty2M9IjfMk9Gn7uWKYS8
YTgIqOaADQrE5lbVu6CcoQ3P6Zdjvgn5GB6vVdhun1wKNnm8Qge2Qvy6SAwt
9aTpkXQcin2Ej+lswAhA4SKVAeR3gZKPGTttsTMohtOytHoPKkY1HVVZo6Up
/Uq8mA/8JEcdyyvbLjFFlwM2i+PZrTmY5tOipWe2Usbru7SX9aWoqYS1Ef+b
rWVHIAJ3QTlHuJ94Kk9JbokHdrg+MMeDYXFzXreNe+XYsTjOjMdhlajIh1Zu
lu7MoxyfhK99qT4OpYNNh0peGNkn4YjHk39uk9dKWFMoUNddl6yP060ODSth
sqqPjj00c4va2AHyxGyBIS104KPbC5amRs04r6eoPjS/QQLGc3ixNoeNMnEE
z61DjZukNoY8DkMlcYoTmQJxlQh5HHJcE6qeLKsuTUdNZY9rQgiLZaUZ2sEv
SxbYw4MhXcHt7CCRkh+dgIKPtA7XSwHoe7yScI0Mu80HRsmQHY3f870tNVYD
VT5nuF4VwyliSanTmSokihqokNyKCNfkKDJyJiEVwNvn5SNmLAXkXDUbWRBj
okyu7FJDgMxvPrXMztxNaw8P9ZPBId12wLyi9P8z3QrNpscJnlui/jt0YIPy
8eerrrx/u7nSVPw/Y6S1QCGcUjnZx6tecryczLmAxzL2j684d+pd/tl//O6K
UXwsvEOs3yrCSB/NmhQ9pqyxSV7kqMrvBILEw5GM7kzqmPC+i8MSCoKFvCEn
sQPjLoc52aZ0qjVhjeAudFmiRLle7FIpynvVojVDEtZwUoAwIzgOSquUegNS
4kf5MOd4a7Ecp+h80BfiGs5v0UuFN4HQn5BXdlLhvrNbl5Mkhw5dIIySyraq
ssRChz9f4WKhkFSXufr/8GwyB+7T7954EqwZDbaSYokIEqOsFJCcBZU1t1aY
4TiRQFex2kT+O8V2GWWzdBV79R37chhbaeR29ZAqHNbkxUYamTj9z5w7ieHd
84wk0NML4Qw6UAEdtmfhHE7HZF8NQoeEu0FThyUlHCmBLuMBo75EhUx0etlV
t54bmXe4P1/7erk/X63jjonDfD0vl9gDockgB8MJWZzPIApu2UXLwEQaEyFm
Q4dVQDUYCZOFyxoiUsAn8p69VobvYOtdSXXPyJppEXrKvgt1Z1Lo+xZLXXAS
MFXn6dLQjVXEaTCcqUhXrcaCII3vMbxBXgS23RPALMTvE0IH7r+YrmrCQzb9
vBfFhS2qZeqyBN76Veb8RbTv2KvHuAeDimnhHYU4QF3FI6eOEn1dE/u4yTNZ
o0MOjfLgmlSXv/APt2BInaQDEAXztjhe1AKNsJVXWamhRU2cgDOYs11gq9Am
PQp9pHNcSmSPIzjykYcqKgZN1ar1xx4TI6y+aiPCUutwiCvHAHc81DlTosgH
NickZOCccbw6UeuG8drkblmNYKOJ2XEj2y7iYySbLahSzPAXnDmDr79PV5J7
IOX+zHuJEzuWGDtzz4EPovbVHk6okFf9IzxDHdbtdxBIEwZsVp0efo6d4BPE
y4GP7WMhWU4Dw6jVYOuHbJhibAldYgmajPf5qKFwj2R545vpS1dwRDyR95wZ
bUh4x8sPTv0VU5S4qI71hP9LYF+s1YjzeBiUHrvGaRpa1OeZOFX81xYOw98X
ZSPgDwYTKWwj5jzENwaUhsSl4GxN9iJgGlsBIMhlAfP8xOrvEgGx7EVEWhur
ruANSDecSi4R6jbbywTBywCU2BXBPuDo+BNGG3amQSWA8/HpEGue9ZBALAWp
OVrYgKZARydAGKyXwZIEF8qPRCMaqyS5tQQQhTgC6SmLY28OOVeIibIQRBhp
1VCwMdmcLJNhyo5yZrNKPJjIgehu+IvZ/K7eUk0Q5Q0o8ozHGMu1ig3k1+bg
Zmd1zqp5vbxFCU476Mqg05nUyFAqCLDaOcoMlpkSCGV3Bah6PQYaXCwZl2oa
g3PASoovUEiX0xqCuwp9Hs58CONk9EEKFZERhVcRE2OVgvQSSx7AAyiYkeHs
Ettv0Lcc6yQMrOwNFS5xQpYC2l0bd4h0BFjCEbAkhTE05uE0q3VmNl/Wjbj7
1QhHiAtm4HHqjJhdXPMLynxqCx0AAHx04XZZjbJC3YJIgWFMMcZEADNRnFOw
x3H+c2yZROYbhu0dl8PxaG6dpVu05hbcaKwLC3MDBQNkA+PKzZP6b8uUUpcM
qS2dzfWNfbJZipaoVfUXWTFWHmKEhYqRtI+RZCeh8M1rSoQIhTSS5pQofjth
8eWiydKZI3CScOJ8RqpxhmJEWFNao0T+UVo2KmGULBdcMhqsQPeiLyQXX3dw
K5pq+57zANywdfk4ZyKfNVkV+IDUqjGz2KT60wSialZNOgn8GmEG5vNypIAk
xrtk3JZkh9pkTDdbPyOlR+kevjQV7yLMNLI55YxHLF3Mi5B1HBzLkkm2ph+q
JXO0tfWHDqrjCKrEQBpX/gxXsxmTGRhZC66KXIwso10yY0B6kPJMNA8tKUoc
0PT0yagrT0ae7mu8PE1hBh9tiDde10WK88MH5uWtQpufnFQiKuc6Bf6gVE05
lMHYY6kHv3CQX7wbhAKJD41Eo480tI29No5drIHDk/wMD9/sPX+DlaNZGCsp
iKg/0sNUsZTy7wgtL0RFvOZqqUVmezh1lLOMMDHIFI9awcbg+kVKOJ8B16RV
HU20OE9BxoD5irJmJoAdZjwofKgWMsNDSbBH04tVqxbQj3dx9eLgY+0tw8jB
6/JODMwDj2DBlgYDp6IilFEGBEenH7WqY27Tk302xYMZDnN0t/kzSsumrQtv
0xLNeDlpkZ0qxQt8+YEe/AZ/rmsuosaLU3XicxfVSmPg2no5R5shCERX3ote
JJcm1lLjR4g/N6pVS33XFhTrILSymuyK4WAmg+oa+ydgXRSPYb/YIpozcZA9
lI7gHCN7wWwtJgSqpYo883rN35aCbT+O2CiroqxhCgx8BgMqUUaXlM4rVjty
A1cvz+yZVc3Im1UbEDrCQhNX7inhu9xgO6Ve9BIV5wyK7049mhGvZe0jcMII
PJkRyM01giMoysawWTm7T0+knHZLhUVREYVwDLAb+SwDM1E9RctS1mzCqa/g
bKMadgAkay5lBHLJeimM7OFhDRfmq2HxP5r6D3Ma59mMAbYX2E+kUXQTqQS5
cwhxci4WWIywgo/ogLNLtrem8Fj9bLDke51GK1277jk9L29wIYL8OJFkuosA
/LzDKgq1Btj1oQ7vIuX0wnpKBgYjX0oUNmj6oNrjeTKthdxNVO0wCs7ux3yz
Ma4qn2zE/Tm+2guQL0y1kxl74ylLFHc4L5Z8AggrNLMAWLpsGMCTcehJont8
qBjLNvI9iLjizMXCkJG9i1JqUIJ+JsUpdLA4SCBqGnlt54xO9s7UxiTN5xzO
il2RselGQXJZXRzv0CRdjDLBtWyioUheGRBnG3qZ7GT154t8Eucg6n5WhK0q
kUOla1s5yzqwSE0eNTRBCj5NU62Ea/mtvCtpzTHr6Yq6CUkqJGqxCozDqO1s
DxYuoEy8xh+34yt6JgZuWB4IPWrbI/UktjmZeqfVEdPamFoPDWcO3okjjZn7
msew5/HW275o4IbkzjZO4DVNJPwZ0O7Dg2sP8/XrgGChiPjuQ3o4MmB7B58b
BjzxwFUPD9iOBitSVrKDISaIRXOY+8Z6XRMiCug0naYixr1Kqvq4+LVVEunk
iRE/PLheNchXYS0eHlr9aDAVhwy7kEZPkIQooTrkE0NmoyeA7jp842oLQgKf
Mh7U9JLY/2g9SYpMTg7S+Sc51d7p0jAaGNV3EszC5cUpratispIcK9BZDm8p
sF0MkOtikKgLB04dbcYeB60iNmP4Fu5EiKkleJjDleMwIVOxKDHTpuUanc3M
BUZ0i/tE5amKizxOpJscxzS8sYaLwVBX2k5l63o5xy7if2f5gg+MfE+U9y0a
jHBnZcYRL2YYnZxDiQTTG9QVUKSCt4riULGHgxi3uA64QIQ3/J3GTeVYW5SU
M+HXzyiMnDxbn1bAwT+BxjUahOouH2EOXRFckQArs8Nl3aEGacqyz+eS6rAG
zRDSvKhpZ3h6Cx79pnWqcgVb0UxNLsMhf1gdqoU7TVTTsBACBrHUlMHz8SI6
aBcP32HIlnTVql1PLHoAHhCVKuSTdvw8y+mhNBrcM8c4eu6JZJ4Otv6SWd8N
Ai8mFk7yZ+zh6+989IHqzloaQmSxObcAVfmJ54CYG6fRxwveXfPA0oU9KnRQ
p2QczVaekCLuh46ieU4Armz3jKm6104BZkrGrRVanRPggajRUU/KSNas54h4
Im2DXKqCYJLDGQ+URmellW7l6W0RWjwtIyoNzBDb1EuOnKtyiT64Kl8QRz1K
9p8kjL5uBV+k9KWkvQMvQdIgGGMxASJbGjsfs+JIzoIsxvLEWmSeOZO60e1O
SBKOE3uFInZlCpyZozKAwdrbfl2YMmjc2BxCD4nl87An/g/JR7Kh/W4fUb6w
GDhiUtL3w3LEprfaW2KBiF8GN46An3HjZojU1kzRgbjAXhCN92WqEyj2iYqm
gd+PcimmhK+CS6PleHKwWINEtae8Vm6sbna4dY2ZhAZT5bKxHgnm9SUCRbt3
iYZBoNw6ixKxQ7lI8BKE0FDK8DwyBJnxnq2EkbP2YZMCKXJ8WvUo6dvBAYcb
9g60GSAseMZRcp0X0ZJYbRseAhjqKCUhODMT1fh4ryuvnAlLF1y9Cfy+lvqq
Tk/ziBGFOc8STNEWRUkbdU8JKFFDqqbsZ3HgFyf4eoMn9yg5VsLb5OztaY2Q
Sw6JjIC4S5Cylk3IuZFLzUbeBkrLFc9xhqM/d/5FfUxwAGpSGmF/SAuDm6m0
sEG9b4NKmBddD0PSRoNaQGjZz8MBcQz9h2mZaCVgCKIQzgSU4TRVOZNPAgRW
bg0GeQlcJknsnnBksDErntgrpvDtY/475lWrbkFFAL4LClc+ibI38mWaxcR6
oIVABJfVSt2JsU5MPuOToD4h9nzy3UQXWrqNjDh4Fl+5ke5jUiPKlHpKJ4OG
iuMCzh/ctHXmxkC4p1IwhW/UYE7UHQv7pPj3HPCKOL+StxOPzx07VQdg2Mgh
ZZVwbC7gu6HFQhCs5BCVwaByzqkxMiqDDGg55Eia08VScpbN8z5MAcZP6iC8
1zwWtMDkxB5TXim5HisBJ6CwELI0R7UMlCjyzdWY+XJXdD2p19mv1DNeKeJd
qrORpS+bud7Fi2jb9/brbTj6zlsks5iXIywjzDGo6rLxS0uMMRg1nCVmtEls
g33LLmSxoMQk811TirYBhjNfwfsYeB+NDil3Ar24Chm3a2UQK44Bkv/WWv/1
vP/XOWrplDIef7u5Ej8UTWjX6qaY8NGVTEWpfxxLYI5SkcinnDHUD45/qknQ
OVKrxB+QWPwWHrot9Mc+mLat6k5fUN3yr2AYDwdCfvhXyaVFLnAZqCtSajE8
gfN04QttSOZSNvR4IZOrs0kEYKBLs0OufzYBhmUlDdZou3ddz86NQiriU+ym
aCFAaM+4yKuTYlMtzDHblZwCRRIpC7+8kk8/1CVWI0GXOkoXUUO8WVf35YqA
GhiZPjFutSuj82Uh6ooD7aZKNRHPYUzBA0oBLsAL7lQTHX6qX7Eccf1NTq3r
yEmEpX5eWLaBKmORaSHBe0kO6GoCw0k+wXjwiclsU0q6oBgRwUugTRc5q5G7
p/h02EHSjqeJn5WBE6IgtMqY28wl3SiOU0iBkH1qqPAITpaiRWBgZhZzE8zj
IebBRAKDibJFQilXR95CyK9DHyCYEMsqdnTOKZeOsK6XC7Km5JQ4ZcCDfTvn
lL+SzyTxy7wYlaJmAu3T73pivLHLTXQW2o1Iw41uIS2xET6xJquYQH8JQpFU
XW0C5VmJc4rDfmEV36V9cgwfdCTVk5cytELC3LRRli0oIk8ZN3H1jKHuy/zj
7MCsnaBvnTxC45ZQ40rOzj+jtxST8Ml9kxHY5kySjSUxw5hXe3ohcinfaHYS
nkpaxnmGh4DxTiYZ58zIwXbaieCfOsrgyNRd5sDmQ4pw8OEKO3A9UZo050KW
R0BkJMs2jFkaIpPBVFboylsWI0mzguMYamVAp1ZntYOCbs/2j3451ONb3lLE
oBdSm4lBBteypGQQr3D3U5ozjdeymP9o6pW7ThoH8N6N4aW3wAI5zkbcVcbY
c301yHK8zdxKa0F+e0YB5QWX+L7kJoPSMegoyUlkZfMlIZxpOh+bryGhbxod
MNiLmTsynN/bRVA9N/awRcxfbE9oYMOy72AGLNHH0sCJw3p4QrgEAYd4PXOZ
hQZlAqJ5eEI8WMoYUq6uT10Yf4hgVzxraTdDId9GxU07KPKSjdpHjtZBZy8U
2LFJZ9oUkTupRQPxyUYf8+y+hcUUMLW0DtNznSy1VHxZNIX/lri/2NSe2SpM
czzMbcyh07er40Qu9Wtei5XR54KqGstuWMhSwfU0Xz8CO+gOkXgcOVwkVzjq
JINBrDok+rnbFY3LaIwUJkQ9bKhsMYXlrHf/CMsnFU7RBnvuxVmTy1vC4hQC
LvsOQKiXUK5nv0knHJzW7kwsmg2RwKMu1nvCkfsG2NRTdzXTLF/FRm3NjZE/
rUcXOQtJc2yBC3PboDWWTYriHae8jUGMkFEiCd5kTi9ALFM5EBYTEM45yUBQ
hRG3guJBlioEc8W8hPXXgA7cDAe76nFey6UObMd6VGDFbuy+wTAT5+OYHADV
dZSPKOuXK/S5blKQL9N27WdNx+JSiSHKV2OjmNMdzZ6Eq0/b6YlYCDdqX3XZ
Oobhu4RKEgMQIQ/e+IX2hBQRFzQ7sUKDjGutaW9NwNGZ4S9dnF5bBDTw/DAY
DcybaKUk86BCm09E+YXReXgGWf2MVqKPScdNDLtnEywJqU9sSYmMLkqSJNae
l1DXYI0nM8lk5BdwUyXHTiqXZcAfkZVTS11Z0cGMhph8XxC3XHBP1DAPKl8j
vVRW1OWseyaOI8iCpqmz8c6PkKJhmHG2NP5RNkC82p4IXPCeW3dwVy1dRIzY
EQpYACA1ic+D2q7JSSo6shBM5LVVfBR1dbvHc1a8ZTfoY3qy0HqH2rTBhczV
AKSPCHIbq++mMuncOcopr0RFEJmrrIApMdwFyQ/MH7D16/3hDVdK0mQHc3CO
yMAYLgOEF7vsPKIisxOnbITFwXZ0TUu0bAswcsdhrRFcPwObmWU/ZQsTphdy
OrLQVe3bFTwg5oIijpRtdakcLaa/Tq5O7WC/lVOVUXTUFOIoxhiMF3GBiLqY
EeDHyWkRhO2QtKdukzvqyNyJ3WbrVHRPHE8VaKz7ykJaq4toe4vMKvX+kFzZ
YY3Pn2ZZYro8IwnKgtCR0whSTYfLInS3ZBKgbZROWLTmBD2q9/6pPAsVDLSO
9Vo+FC2f8ZSi1dKTKmDkgMpDkR/clTnQAKb72QoZfMlAVLkAx0haDoakKPUr
HkCfjzP61nh7dKsi4qHC0p4qQzwQINIQOGg9X1KuVhvOvEeQc4c+cNauMdih
xQk6DYDriNVtGdErVf92FeJpW1PyumjyB2dH3uUOYC+ofjZXTGI1GfRrFi7v
LlUPISEGYkCvKNNCiCXzahESuS4KAjPTNveZ0B3hxClqTXTuqLaEvfd1G4TZ
fExbFyC8jjq+YJaCqrIuk6ZvhB7bZFhxu1lyGKwngvbEjdCTzKWT04uaILJo
OK0cgj9o21GKr2DaQivvfiMxwOnr05Y8wqTJVUtHZpQ1wFz2cHkbTv1StmrF
0oIO3CqSxjF0x4fj5PI4lDWTslDPdKUpdC8uqPPRhV57tj3/wp61lcbMQyU4
qd6Cx5rA8/WRa3XtQWcJKqQ0vB6ptdRmc2NbDQL8bcpZxm5T8SHmSu/SALdH
kWjtvUQZ3/CMp0+ecB4mGyM5xlbcMSLPGvVaC5PTKXmUP+yQyfamWDugipkA
oaUQoCG1TIHJI3ntIve4jPIlmOBM8eKOdi1aEvw8dbFwq2G5hlvP7p3FyOy3
mcbf2X2aUqEAmU0aS22oID3iWMwfBLvFMJZ8JMRSjFCP9Gnc9FzVMulIOEhl
C5wIDbCvnkIuw5KUAPmiC+oES45mUti/KQp7ZIGCAwzDnhcyFVo2obH2+VxD
XFBbqfcrZz5EQl8lJ15ExoZ7h/R0Ib8DhQAbp9Xj3J6+DNpLUJbieRnUTBhe
wF7QgIYeIcwj9InbhGSrfEnJTBKLcw20tdg/SdiU49yvaCoyID6apMOF48ip
q60lODhKrvkeTkVFEKFR1rF3nhxDzLxrR5mqmcpLW6MGM6izz5TGE5O8guko
shjJZMrKlL0IwEbingnwdGW1xyFJwX1xraBfIQ1qkwtZ+QatXg3e8YTZm9XS
G8qQE9EqkcTIBQakd1p4o7Jl5JPG2k9imfWuX+oAEiaMdv2scYTQXNpONQpZ
ekCB7B1i/xGHtoJ9bBxeWoTgEzUm12UrtVSgLrQjjZJybFpIkfZh2cBcX21p
VJB0BC9IYuLHAFfr0a6RM2VkqF7F1KNgwuRLLp3zltNM4MQg7kJofAb0ukf6
Eyanwi1pVZEk2ZtlCtXAl4YKrpzRnfcyBnl2vRe0OAbfFz8Yniz4fOF5tTTV
xgqnjtfgSZInwPGj6A5QBRA8iam6XlKZQYw5ZGtVd1NHS2xh3GB529e/Hx5e
Xb0+ebH/Yh9zx0MuXLzD8mhddj9M6q9mHclpXvzMl08OvidFzij7UJNZ6NTS
Gbx0vFB7h9KJbKR0rC94YWPBKwVZLdnWRZ9H0LIL10rsRLvTZNl09Es65O5E
/jYqYfPH8PlRcly1jM7Zqh/wdBhEp98q7kZ7RcpLK1l6hDaYFK5LbYFFCfTn
znA8EP13Fx7lwPzJNyZoyeZxWOOjLb556/LO11wLfnIvQPKqq9BhocVbghBQ
vrFxx4J5Hzwvcuh+4zOnV1jPWPfCYK28hNUfN2scwyuhE8kNJyaJaRlKf+vp
uxy/RFGZNx6uWRgERmZGYR1+W2D/v3Vcvx3Wz8ciqPA9OSHGgK5LRrt4QH6X
AOtRCUeo3fFoROM4veNetpNMeTIIJTUNx6VwttnocaFOjkrdv6ABByBr0jUe
VS4GW9dcjYgZOGFFnf0i7igfPiUNN6jKrcVos1RN0uIBRhGisljj8qF6Vcsk
vZ1HYRTl/xqLQGM8uQ7NZA2F+VoW++Fb+MhZEpwcAIyzL5VM2JCAcir3kpsY
wydKz374VvLTOpMLMsvMRKXS4pjicNXdsyprSo0aLdFC5cs0SMCNK3xVjykL
k4qBpLCYcG4eSHcvuWQYYsJ3EU8DsGJjOWYEkDvYuvH9pHvqSaJ5mM8byKcC
dZHVXf22LscNmV+uG1vIRiXYgongYVXYpxwDXZdvT+pd8+YaEi9VKinX0OuN
qBLJBKWFk2YWVmhGylHd9F19pxilGlBBQiLRjumBiZZKcg5G3HqbyjXu/QjC
fgGRvYMHVMX6VtGZm5YLpPBSmEoADPg7r1pauGorx9kMvULdinyC0Q2P0T7b
csGaHqMLHd0MqB4rh2cTS49FGDPrrBQ21kxa3TzOlRxsHUcuLv0Wi4qMzZML
1jIU2T8aEpxCmaavRtEAW4PtjdMQfMgs/pA4M1WVM+byEcwEo63njbfeBVeK
81J7cSkkM3RX1SZlXdRacFguFzPJJeKm5ilhjKmZ6ja+vP0FnXTiucKDOuTS
9QDDrz0RzgUjWjpva5eKOFW/xOSizV2uCGk6ZFZKAyLc0VpCb1ZlzUKODwsj
U8CAMfmz5xAuCiJjHkiAzKZFnqMGVs/xrsr7tzcibIWEczmOwktYm9cMFY8f
AbOZzZbaEIZcmXKv8NmvX4/w1HGkjJEr9SWk8zmmQbLb3G+WH0zbJRnpjAms
pgU/NK+1EKINxRvOliZO27uQ9GbLLODfSUd5X+im52yYRcdPx6IPtYCPjA72
61OWLYiSgwOFiuuiCwdR29HwLUZK+Un0r+/+ae9S//d7MiK3wkX/G5ugnoSZ
fknowy8iI/lvvdY3x/1/fv1lSasRb0dP4Y5/a7dI2tbIz/NXbln7tzbOuENw
f/0ftoYlgoAH/k/65PHO1V0v4X/tfrExyWu32GsWRm2KZoZMPWKPqctPmynx
BUz4LkvcX7GocqyR5S6qGaGSSB4R6DRUOSjplQGjgqK9NpbITwp27y+klgKh
kkatThmngfaExWsOGInR/iifAJm7Hm9gkxdYvXZGkOpTUNMy99ZWMHQlxbxm
u1o+ZfBUs0chgyWinFcBUOxjSv1kJbpXzZ5y06olJ5P8xcuGS/rKhaaruzJa
hR4lYCdrX4D3mUKmZkrObVZxWpOKPeKW/12zOcpIfuJppvQmkuS18/xjm1/G
iPS6Em6DFQkkNFTi30HQdzwoH7NtS0CGGdakB8yLuS0Ifx9j15kcIW0l7hYg
cKRYLlLItJzgQM13WUgVoPvS6FObmLvy/9ryKwgEOR8rjwaZ15dAtgTlQwc7
ke3UROWRLqh64GIBnNc+5222MgcKHhJUS2PHtgCgVKuBJDPQJc1qYT3Z2LcH
Wz8qq9B/pAVLK8g2malCXGe7XICWPJLU5wU5K9Qu+qQJji2pS5GXqKdKBFTJ
GhpCBDslJMDMckeWKpPuIEFHN8wyVHOmqUTSPfhmTCacyq1+d4cJ24FzY+q9
aUZdGwOj2xEdVCslYsWodsdAU1x7yQr7umILU8uZyMddLIpWHwg7ZzivM7R0
u/qbPjxcfTi7+dEwIT6eXd+cX8CfFH5PZ1jCvqJ+OAJRx2NSAzGY+Q7TytCG
4kIdXIRBd9m3JcaRpsKiQpeNzamysKDZHvvoHtMqiZdbmMTpt6LadOhAdAww
HsMdAnuuoxTQUz1e6dNiqdDqtfOH5ESL11CbY71bZ6I2WDArMSS/k+/ylNnz
QXv0OZ+HaE6nIeNK7Szn8PFFYc1vBz3O0RM1wmz2reRV+sfSWnE1T1q4+AF1
oMHFQrJkvOIiHQ6XVHQWYqck1B2MjRIF112wjy8o8SRFLHElzJieO6QglRWe
qZji7LtxWm0OKopn81nU2gjjCXeZX38M3PuKhMmsvAV635Fh7NoxfuUeuO/C
MUMyEdV1oRlsLTDYSsJQ6hNl2gh8lo54WGeKlnCuk9zn4QfI06WwXIRO5dxS
FSWh8Uqjn7bhPJ2cK9jlaQFD6XbFUOMddCZ+6J8+XPzbWf/48vLt+cnxD+dv
z2/+8vXrrl+N0OuHwELNRY2CKANJVwuWuh32fNih1ln24M43tvXxJd/satGf
R1ERuqb2D9+E75hTfRMNNETRdpzk3/X147+HMqRBxyNn0Q/icMMgdqqsv8v1
eC0YQ8dS1qpPn3GvGqnTrTLuUB98JMJTSYVS5eObv1FLdHd0/wfDgQRVENux
s+9+ROZcdI534RGcpB/uj04o3j3n9nH3wOeXs8f5FBxjTPS7T1f4ZEbNb42M
qDw8fF1+0lP4GX5pXmB0qZTItGVIqPvHGgPVQU1CChMQGuegaSdVsCYtx8m/
8CXv7qhc81bF73QNCaiyVqKg9xpxl0j4NIdrgK2tXm39Ny49dHpGaLvarQb9
miAXf7wPakQ5UlMOxqZFiOz4Gj7vq3jsPaoQyJl2egGniAqcNEtwEuLp7B4R
y4eIbCAEQo55UrkzLH2kEmv6gluedWEi6rMYMU6xz2gNQ2HcowOvOEesyke0
9bKL6/Mghc9wIde/VyUYiA0z2FIDmVb3122Ga12ChH2di9M8oCGrcqTqYQdw
rEkUI46eyxz4FTqQwIz6+GGvSwK0nuVrPthSh02GWaaA8uT8RPzwf+hekzxy
cOJ1ixe1DjmOwh4cWrSpUS11i0s+35J3+SMYc/MsOY5jLwYhsR59gW9f67f4
8Vc67HP217soi4I09VphGbH2xMpXrEyyXMSHGMGxZuah1xADe8Vp0tWSMGli
PMdKTGhSz0SvRyRb4OA7LHsYdukWsytAvHJhermYMorh2hvv4E4us5lUGedV
BCDOwZa6tMZcQMx5mI7pCpAqg5xzUmrlmTjGwIaY2eYiWLbX0u6+mXItpELm
YnZnMcJjO4Zt5WRJNd0HW+95t73jRGSXxjUC9Cy3+w3msME7O58VZ8mgbSF+
C/o+rT8BHZ2S90siUpx/LBq8rmEwe0xF0uwbc0JK/YWIAkHAsCxUzJW5YzIl
kGWwQWecUiCI9NSYkqA4uIrgzW3e7KGZ+ebt2Q8/nWGuBzsW+Cm18xKosRkZ
+NTCN3P4U22unTeM4Ict5lCMsW3jVoeixWv+lTre+mituYGJeMN8Xry6GNIi
FyjjmkF01bHRSE+4CBiiAzYe/q6WRMhhQbHRRUkOQDu34V2M3EKRY7Y/W++4
XY4IrTcwJNfxjUdHxXWMJiWyy1wIXMNOv1vXixTW5BeMQKqDTFJy0XOCnE56
hZaErKaWrQbOZNfYyUAxs1rbFAQwh9lKcFfYmbIyPAnXxKXC7g4Vg7BEE5YV
R5v7dB3xP4IxC8jDIdTqAYitSL2nfPt2mc9ovW6xO0ttPY43pF4A46Hgkn5L
aYEMa8hJGSTfuZ6hRF2M0sOIDkZoc4UlRiQzDNfg97RYIdksC1U8Hg3JYdql
xYpChKyLEuYOC03Bt+hsskHd59PZkpUHfXedDauMXAYjVy4LW4EsQ3AWapsR
5nNguYkiC7IV23GDOp2AwqrVovHnjStJHVxS1cKiczoluhPZm0UuqFlmqLrB
gFakymUhL5NKhgH6SWs9GoQQUoJQUKhCHbJ2i6qzSF8RnMVbbkzuUh9ZmaWW
Rqn0HI/fS31Z8OjgV6olra1QT1zrbtnTZQ1zolbjjHLNXbxYSd8UvvSKAX7H
igH58bWPRGg9PjektgDVyKFOZuQsO+iIcw6AckVl4eSjsmfwKt8YEXJ+VhFB
gvAx0Cm6GKq+hTJhODOz1TNB4T/ipgOVcmIETHKY8ig3aKxcUJrPSuQYx3UQ
iSZ+sHBruQjyHKljQSAUdsZmmGCkG+qONmWdym3crq6k07/+EvWEK7Ya8V5k
yQa2RuTMgL6GfXo/XSWa328BcZwzGkGsX3GnqRXn4+GbaNpSTKgpsWvET0zb
d2gg6Wnb5ncMnxPcRETNdU5RZtihuTvMEeZaONChFWzLglOEJc4nbHsdsSJH
5HZwJSNX4ycnLC9UBaNQjQyMpxEyKZCVWskcP1Ei46yXwmxRMsmD14p3WCGS
1OKd5QJTHndDGY8EhDx6Nylsjg/fcmc5HBl60+Xl2O8RiQKjv4Ldbfvaky67
2lEEU3LtK24gzLGA0DmXcKaSog/KMt/bC210nYysqfOw8E0dK8qBjGFXqV6n
IEs640gTa3biRwzvE0NA3D2ePBV3PHo4P0UVNv/8yLt4ff7m4vjt16+7g4A3
nkjFBPVtMNP3dpbfEXMU2V5jYwo1Od3rGYQopO7rY0ItJc0YtALaEYcuYekW
/CB2nZEpj6D0GF3t6MPAXWxG/WlZNxrBo/GPBASRTW3dj7o0K5KhDEcc31si
5L/6MFghINgvxc/kJ2QjDu0WauBQP0CgcvQhKL9vca88WEkhN4nJBFeGxE25
DnULqk7AGZ3TxIjgLJggkeBgZTTxURgtXVjGHmshWnUwIVflc1l51MIQqVdj
QcuFCV7kltD+1KRxNgvyduQ5aTXLKS1cByDdipBgtfCvLktqZ2f2DopkPdZg
0bmGt7iIeWH4YvP0cz5nM5iB2QLh+6GrEqGFzk3GLW5mFNogjFw6GJQYDsuH
KXalFT6Pc6BQ/EzbumwY5wfBQIDFa5JPRXk/49YwRn0wiWGU4E6Y6d5IxHyy
Josx12iVuo6WRe3az+NijqVUD/0ad8fywpQQiRzf7TA/NzcF8brPNeWsnmiS
UlAhI02N1FKf4CdZqg5l2vRKMg1AT6DprRXCgAjLGA5bVd3jBb4weQ0v+qSm
r+vJZxEeG4xXrdYbM8zThTs77Wy7UHidEsOido3m5Gl1BtRHOG+FoM7oshuA
RuzUIYEdJemN8jnaFpKWa4kLHMgbTruXaNBRvOv3Dr/4ip70nWta6N0NK802
GwoUCfdrssAtqfGksVpUepMXtfb6qFNhpAvOgMchsmVXRKtj4JYrJ99gob+g
nS7SFeoKMYi0tLOma9txhZ0RGroaBnIN8xz5u/C0NTPFgz0TYKVi5aSRe0F7
IvTIHcT93PUGM/vmrIVUNW+JgXot253nIh3HNI9itvJpATJdWw9m43W5YYr/
yJy6I76emq7+BLTkZJcAM5Bm0xHxUBmEDTLu+H0WecSkbXiIGXFrbCA0S5Ew
0L5GnIdpsc7QPBxKvsgwuZqjdgy/SKaoAzbxLyIG6/oDkKHl+azUysR84lUY
176LhFMrj1gbxxO8U28m+xAcC5+hAxV+E4seZUTmXniAATi84VMu/cPiN4oH
JgYEbhOok1T30iRJ/ZmywityTrj3hlCvC+6yI0UqlrN4JO7eEKH1+WFYsaVG
HBc2a7B203Oe23OC14HJfm2C5BgL6iFN1zpYK/UwnbkXvAhURtlrAfidbaFV
a7FvMwlNBaQnU1o1wPjrEcbomGV/+/p/BOw0iPAu0dkVRmzVRuFmSgISxiDU
LHOP6bPPvl4VTfpZ6hXU2BAb2rIFMAR4m4mPSODSYsdkWW3cURib4fhvvJfY
kx6TzWInki6hotp0am0gzza1WAQesrrVNgq5sBWhSGPirNUUhXavY1sHUn5k
/u3rdJzBmX34tqZfOsqLtuCPRU5H1deRuEKgPKpMsfhWL5ku5xhARxhPccFw
ohG7RwzGue0T4aG0nJypptUQ8IG01goR4aKUt8Hec/YAuiMmGblczosIdZB7
MOfSCAQzYTTMi7IFVXK19+iRHYE6VCL6WocfgdGo6GJdnGrcqPS7NSVq/5xh
7Te5jOp7rEZl4BcckkY6DAiaw4MFd+H1vZcnZTkKkSx+TSgYspl2VwZF5SoK
jK7FYmhLRhoa+RkK354GNXCBqq271qwqb0vU3K7op1jVkpmJfavQiqKrewGt
iKp1pWUdmMBID2g2IrOSLFLqgJBWitVEZhAYY1QCZbGTRgrcqzpz+4mfBqIk
MoYFCKUTPE4sfLLIVs7O7oyBMGOKxvSqJeWKcewutrnd4vmGTmu0EOV38+7i
dDH/AFNkNMqmYOGyvpikTm81U8G/bkNFjTv4XaMINpZ1Qg2GkmaKm2inoSLy
cJVPyoocQOJIEo9fo/new4yaVchZCbp9nxwIcEiU1dtoLGDCowznQ+F6LV7d
1Q082lxRZzQ3hUCJnVq3LWd+m569jS/cphupiH1EgkdDmLrvOvv7FNE9qKFG
Gfe6k4KnkMod+VvnKY3PqiT4mK64io+DmgSQP814JOJmEPIk+qf3jbjNM8sT
dX1Y/Sf1+rE+wtFGk6dz6MNl3mBwwT9pUkMMQ2miZ6nlceY+HzniKJk1zZDQ
RIsbBQhgnXrU6UT3jDUoOuXc7RanHVwuhgiahhRzSfhm9oCuMqkUDXRMZrN6
S10auUWwiE1FWiZXSTPrC6J8QliBYe7iixHTw9CSOJeTKkD08RhtmGAUcLKE
Ewpkg55lYd1RrTbrBKZixCvcRpPxPj7laKMMsbLjCJNaX7YbJEo56rGZSzGG
hVTQaF4x5WvUvhGFzQgO5qllfcjDhGI1lyRkN6nuMOW0HHHVS+PVUVfesrpr
DRCM1jOjHHuHGIUgMqGmQIZxy12wKF2wIYdsB+pXEL2YIRIrMibawlipGYEw
uPZ3dVNyGxhG9wQamGSYWVGGwo9UXkEQVwUouhELw8M+tmsYB44g5FkBkWn9
vSwyDn1Ffbew8iruiyq8lRtla2RUu9ym1W0Ok8G+tYGeXMKZo0F2m9MBc6iU
cWm5pDqZo2GG9apNSYdJWzebs2McKrtvlxO8CwUOB0EI8T7gNmLakWgXP2aV
xrDic4PwClyxTFy/XBJIxzQbfmKMFtJzuIk2YkAhoNyywMW0zx+p9TldWsWO
ukRYPefdiNKNEF7M5eXIHCWk5Fyiac6w+74XrgaoY7c3o+BPNCqlLMdXm169
Pj9VBzVZexWtGvCvT6Ajhww5GAoSUY4Ym9iKGGMyRupDkLJcdpFOmM8WcMZu
V4/kW1jvTa6Fx4BuHE53BSDSIdIYXABE9rS3oV4lQAzykoe8sVYvei1c0TOg
Dl/mFkELR7Yguo7aUiNat456RW6lfJ9EMJ1Mg0rC/DpV1R0xGsYhcNa7DAwi
JZ02vkEf+1EyhJCODHM9MCOmg1J/reiCgNzY8/MInxeqsNYjsk2syw0F/E6t
U775VXjDvr5BFqwjYdu4uiRZu7sP4o40St2tEd4qdFUo3w900yG1UD/DbEXO
v1ob8rN2GxzdvzvQeyhdrHNb0qbFP1Rrl40JITMEsknOrXrNxrqOjvPwrX7p
nTsMGXIigLan2lHpQtt+PnxLWJydlrtcK7QlUIZZofBwbIhjHi73BNn8kh18
xy6oJ/BDMjzqNB/ZY612yz2d4Fq5QKCvjaOsIZTHsArNqtBdQokV+SQvFMST
pTM6SXpMhzxsOPuomCanF9dCKahfaD9EglxXm4xyM2qKz2IO9WxsEUr/osHW
D6WF1hBojsqQ8zs1+qXpABXEcs6VJJKxDkj7ySl5YrEpd1QWtm6QvdZaawdN
bvCsoyodY0eEBBZdTw8jw2FQkJuLJjumEUl/G3IG7FIuDTyohWWo8S/zP4Ze
ymkUmuKSP9xBjnYGQFOpI8BbrFI8WkYDIIdR54zHpvpoYf4td02VmX+P8dw1
UouBDeAd5NWzrSSUItBd/Thke22dO2tz4U2UAIPpkrl6lQhjhugwJGMFGzVE
Se3QakUx+qxQBvsnklPnDaenX/NSvEWC/iGdiTDfeXP99oddTMWFn1LweVys
hth4VRbPRSY1O5ZCA/BMg8W2JBhP8ASY2FqRZEfb0bYCSUBMP97cXOp1u1Z8
jMaKVYtxvi+unB4QZRAEH8HblgkcfQ2ykUW3IO9K4QXtHFXO/yIjlU3mrhGO
kvSP8h5sZu2EwXlA0gOB5I8bEL2lZEgr4r482ZhatmudJicIeXpDUZmjDaAh
hHmGRmde49Fo6mw2ltx1qW/EbAFkhbsqIBm/mzuLC1CjZ05YaJ7fpdSnwbIq
DcqrIp3QmlAzpm4cH7GIVyFVNYVh3EnIYyJ/YqvyBiF2Q+S7wbYHnFz7Ggat
JcVaSpwGmPSoG6I4Ic2rCKZwZpy+J1MjUWYVolJK8JbaEO7vclCSyJpzJcOK
NyXmLdXcyA53kgDqepLKHRV8i6Ubuec9DJqcmNAjnlpcuXhmHR0QrRf2dFch
fFqGDVCcPLLjRWPU/o+G0Hq70jCG1VXEhrl1sw3N67ljBdg80niT307Bcirg
xd2kZp9NAD1gl8dg6+com8Ht6fX525+u3h+fwr6qLDy+Pj8RgUoNZGSNRD6S
eL01bsQmfVhzGFfNqXxDUeopaQTJZcjWXhOV6Lfqy08unNKzQWtPsOmGA0wT
oSVxHQcIqCwdY58s1/RLmvrx5eXJ2cXN1dk1IjIabB6IrFjgueK+Vjs4VVNa
/XnHac0ODqIL4tkW5ifK4pZ4TO7SklRAUXZ1XwcyT+49Gg1Ac1Vlv0baDIV7
hOpqWKN1660XZcKExpHsdpoFCdCE8jFZNquoHJFz1oHho2dEIOO0fddwWiIm
w/o+rb0otRd0PFd0D3uscIe7vEIGzcj5TtnY1fe2u40GMAUhYKWBACEM5JGt
0QPs40YyaMootqZ8pYscblcO0DBNtum4qnDc7lwA6m1t4oBnQ1D18Ig9S6jC
q+gs1jksiJUzuE5ca0+uB+ubItw2tiGolMa4746mGJHsCH1AJcpD+Yjcz8nn
4a0fsfbOhGO/x7553SDH6d0mBXR06TrJc9p1hrZEnybw/IX2W5jmC0/5PTpC
LlVFOQ+fpqgpcSVJx10yRPu7OrmxyXbuCKN3xMpdywTpl3D1p69fj2THwM48
jBAPlFm/3Xc75egSDTEQjJwOIkjg7rZ1u5GUOxQLcotrQSz7pR6HaPlZvQdq
XVKugR8s2fFp49OM1bLBPfD8x6RlmEs0ODmhrIDshtJq9Y4ERBgFLbFEau0G
H15XUiSDByJchdthkjkgSYbXp/H67LYmdyCTSyvTrwKsFBCOHnnqqaoHyHev
iZPxOGvfrQqjivqlZndlaCdvzeV5c9VdqRmnWJu5iX/JS8KBzKJWSCQDyjqa
lDOw9QgEyRL6D1DufWupsIs2pzVJaj6cHEm3C+j8AaFOcbwV7984mYjzNhvZ
zKWpCEViwkXplQM1bWZl+YlYBVHDKwRKrsseZyPdq+s9ajfKx0vRH/w0Jb2I
90EVvluBy0CVfmzqmRb19QK9d/C+mOhfySL6Hd5zmpMsQwe9Z240K8QzUxoH
kiczSt6tqxBP67kQOtY8aKBI2iUy0hkygIgLeco2xoNEQ8mdDUF5/cYt1Ng0
5nOjtwwxJ7CNXJUFii0rT5zM0qm4heLeGDKuBHVyXJo8vc111oFXcKoULDMd
1v7r9LbKh/207qf9ayHBnZPXaXq9i+4y/KXLX/az868kIixdmq5rZaXloOKu
T53NjEI5MOAzlEUF1oCcF+P8B+o7sxQjBW5kEX7Qi3sCsMeBo58UMdCHI2Sr
UJjseHgTF9UHEHvYtFtZJ+r/46pYji/PpVgmoIfZk+sk9GJyQHzTVj6XQe+S
xiOKEiLnik6pSGKb1hBk7qXhDXGKstz5yE0uLVYNX8oOGWkgS5ok9Uix4DB3
qc18KYfE9DyBH+vhRsJ0lpzU7bs3sXkTlbyq0U9Uy4FkIqY+uX7oA4rr424u
nFdLb+tF1aSs9araTnGgRUX1Bmv77LbATF+8V5+Mu8nbbm7SDrJVyBRnfAjI
igSLuWqr3f8EBsi+nBYRcANnbrWqHbyDc8AycJzWGfJwWES1B4i+D0Qf4Dio
90dy67nNjtSfiUVkyHb54bQv8ZYgQ88KMHQNNA+dq/wRE72ldFlfN/bxoMFD
5WvkQ44WwTun78MgKJa7DoLCo7LnkrLK72+ltkq70DZhxEtlsDSaHuH77I6J
B5LLjmJYGLy9l5zqsFQZCRvKm2zfKkuGgX2XHkZOgzAMbpJIyxwyWPV+JskQ
lsyqvsWVwiN27mnDZBxc08mxMtQr5PWS9R3gDuXyRYlZPaDjJeunNbyCwtKE
hNmQ4yVKnYg9KzZA5aMVqPP9mkN40eOxL2A25eTVkAfHCTcOuEEXjreor9NM
pf1ERrCWeU3xX7u4SLUlWFRqousqjZqXlRWWYqnokrw33DQGbScleiyYaSLq
8vlwukpGlTv1ruWPxPSqCOjsYXMNEGPzMSJSTIV3b05Hv8AwmVRErK0iNkGZ
PeEJlp+70zq6u7oaKvcwzx5Hq5HQzijADR1zVn58QnPkx8dRU40RJmKwD3yH
QviYjLFrZrfzGIoYdygvilfFm+QA8ZUbFpMO/seI+eslQgpaxzAjr4nUWc/q
JYdv+m+PL9AdeLzfP3wDv3/9qnKdaGoIgyQaBU3vNiNgL0tXc6OBb8NAtGWc
4tPbM1jtKStWH0h7Jev3/ORC3w16OqPTL6XDOPXCamtsAVacNAiZhVtTsOLk
JvxCB3rHub+MECmlr0UCb5drkdLYg3h+SVSMYQ51L3q61KZN8QK3BBblAGK2
DA3YUl1jjiHz3dg5cbAFS6uqvvnAgp2g/PHh4e3+R/iaPFg1yRk5/2rxGlYK
0KFI2brs48GCz7cJVKXPDbq3Y2WN6Mp/ENLGaQm3NWnQeoCSUwGWciROYE3M
V7m2rqSR/BFjRWRPkmz9k27g9hH5x/zC7HFVrTpWTe5hCTnYu34MWzhRzASF
3bieJmxu+9Pq17jnshxbuIHaLLUO5npcZkjCS9Iu19uYSxcdQcezo+oyoNZv
CoZZhyMxdoJo2kXL3fsrDnY+xoLNtLPRc9uxSxS9C9skfhNzwKyLoci34fMI
YgnhL3vEe4qLefD/hw+1PdFRZll0NNEub6bZisFFL4PxV+1Id2/1NCc0DNIG
XKizaand6kKodyVZ7Xblx9SUDQGDMAYJx2TRIasGaqxgb6CqDL23w8z6Wnbo
KJRnX0uvO9PnnKf5N3jFlIXy64ijKBGY4wpMBoEp4Q7D4Z00ML5qrdUbZ18B
z1lmPMv/akfxvnMUD1F1X63R9VpPZDq/rg992B5mWq+i5+931tKFKFSH8tVS
QFnpNzNSh4DGaWCNO0xt/mmUd8qJ0ZRKiKl/As7blL1gm68bCbs9VymG2EKY
S+Jq2HiFVMy3G1dpRFXFTBeHeOWqQ+Nxc/FA5FsJkS3x3G2AmPXLfrDm/193
5OMZzjt6hVLCPcMau4Rv5xZhJJJ79UTfZmsyg1VLporMt7b1xgT7TXV8bckV
Zhm3F4tETzzpZ79t0sIm7Bhu4Akke9VeIhZD/MSsGbak8eaWwGA0lbTGpMBR
iFLHYw01piKCNOE+5vpdGoNXEyUSE9k8mkgJVEnNfxwEB40Rw2QuNX9dkPnj
R43xkuQja5IhRU8aq5Ga9vAtKprwFX4ors7Y13lD76nmyTeikoYeueE53yTc
KkGov7QsKZ8nc6uYiTxsBRDiZBgBzYuLXlm/yquk9WrJKl4rRw7x9uTymX3T
A60yK16jOK2Ws4w7Rxro8Yr5iGW95bXWqzICCBc8tPp8uCwwhZejJDxrhC1Z
YYLSEo++Vv6CI0FliLBsuJQmXCKmA3orzVnJEsFZj9YGe5x/Zv/tfY518HVt
F4EoegTDSaJrWlQXFdtT3zHeq+26PQnq+3xMOgo8nVONpRM1EzAHX2jBJdxf
cMAt4NhybvWQiwXxZpoQBRu1zWMpLZqNxBmlh0s5qSciJcCTGsr57zCs12w8
UprbgkteMCqhD+W8opQSiqQPClsjHrQMHvOB215o618LQQfXEh/qPR9+ZzS8
silB4at72sWba2vo2ViDjEunXV+Nlyl3sseb3mV9ofQb9wKkAEqqDAl2KdW4
FN5U4LiBfF7PCGnIgaTaGJZ1JgUjKYJ60pWUQY+5DiQGBEQKd0xVdR2NBlrB
yN7tmVEPB7GF+k6SQHq9GiC3PmRro+f2xpezGuKNFjrAQ5VCPYXPCSPjPgBJ
wr16im2Ih286jiD7xslX0TbGzQm0Ci26Ar8hvjoDTWKpNBUXeNYqYuYLNQBo
BXRYPabW+KwnqKss5i6F7sPl611JQeX+KPK53LeYlgIkg13cR5KJhZ3sEE90
14p70lApRfkZbZgaQQtd1ppHfHlxihmEIuQOB09x6R8ezvungyq9y/v5sKgm
/cPJEH/7+lX3jMkqwCGLBIOl1/eHOgwrlOaOzAbsATRM+6FeM0IVQ/q9R1Si
0JGUtOeb6/2DweGTp9YuRT7YR0eLpVPz/qqLYAhaAqx9tScaAkEL0BnstUcr
AovxaGTtGMtL0kmZxEASMDo1jYkhKD5ePEUA0yDA3cPs+UFPSGWQIX97wnRQ
I7fg17PzjXKxMaWLRrMbwdiwgJB7JagnpGIEBMTyAdXqM6M1yrncTT6cPQWC
O9vH/xzQcn44eyZQaRwbwG7Zsjfupaf05Kd0B/++j+o+68bwiF0RuOoxY7Ua
sUg4KZHcFdgwmiHBOOQaIVAtPQgOneSLsuhfLkHzG6rGMxAdhpaaOJxTDlhZ
4eZXkv2jWh9BvKpngdcPJyIkI5XG0cNNR6tt18KrgpUUH23mIVb4pppQ3GEw
arn3W/4N8F9yw+MayL9HbnXjPOr4+uiRWx0GU7j1va3iY7e6fx83vPU76mP3
XQIGTxW4gnzs/n23fusXJNxfvXKtT1/01kev7Lx1w7/fcuvvfOtHmev+prky
Kfpbowu/+5VXvxW+4m78LurU+GuzvmbRIh8Aqdn7v/st7299UIF1i93s6U+Z
+sFv2+bjy/Pw5+9f8F+d8OO3/u63fgc3Ief9h0n6y9aXTW/9tWfhrb/zH976
es0wcSby47f+hn9ASkoNtrV063ed01mba3vqsMJwg4otP4RHnvrIWLvu0hMk
b/yP8EY5v9/htPTI4Cf/e4elj/bw2Uo2PVSn0erzaXqHtvgEOdlyC0ReAWyF
cJdn99jrc3OM1Lyb1oQbO2kuUd3pSfiDdXMw/B8erptylRblHak+BiQAM+1w
J0h5uMKoqWJvMjdBYwCMrwCW2UNgn4BiqiFDG1mIY7FFpp1uumyGmq1ykdJS
Xcw2uLequ+JVHze7SIL70Sr+JT+SSkTM4mfDGj3zpMv6J0h/1QBPiuVtMyox
TdSZ3kYNc3i05kYIaqxY696HQEhtbSdCpNWhh1yr6lgCICSX9IpkFNMcgW3/
kJyH+v+oUIj1bMvENiBmdGWLCl7v6WIRLkjk94j3hHOLUk0rEUT7Nk5I8CO2
MBycTp/dKd1I5RmVbBFOcwRloFgnIZE8nhA1vOdqrjWPjbaxkrxT7r4w8sRh
0fD2zvveCJfPcH0ZOLZFbFy6oG2iOyxb535ivVmdNeZf+FN5zY6R4DYBVRxW
Kl74nuDjhcx52+G86MMhw7TozVstE9ajtLEi/ZAr0j+EiSjPOsYqa+yCgL26
u46ydfeRV9qyMN1Tnax8gnvARhmvmFuwQRhb6GVuFjRlV/nE97gwLzqQ3v9L
xk3LyrdmU+Zssjo2nSrC91IvbtwbX+7Dvn+2oMW3H5Yb3VZ4Axl0FFjBoEop
DYwN//KQS/OvFzNuirV36ur9Ni4yvo2hpGPvZxt41LLZtZYPQT44hNiN7EnQ
XRY4Jptwri3MfSXiIImOtI6La5OlH9WtxM4pPpEStBjhnjNcs6bsDSkVXDH6
dta+pISYUTbn4jZXx7arDrXU3KcYHODqN01loZR3QQFaP5e/lczSAndgR56j
bCKrKLVN4faGv4Uc2b2zpB4x4snFHtA4akZXjqJHg+TUBXm8Dc1QUVhTKo4O
9AZNkTlN+0NgpdWkDzym7i+eIQmYR+YaCCMtUvh7x+jdRYyIGHc9aR4cJe8I
jpfs2uFKo8hHIDB9VkMdgsst150Qg2gfynLJB0CxiJYeIBb7egSCTrKI7OQ+
1ZYMSumdxySkvCNXAr3VUOnQe6KxGzwag4Sh9F3w5D7jtGKOsCAZwgYwNnEj
i8F5WKw3xvpWx+GqsjlidzPGeAihxSEydsWNU+pmQXFVK1IJWZmbtu4g2rpn
wFXEQ39kLRP9W7qCIIwvwtBLVlhhnViqvP4UcVRU25CYiYxr+m1sDDSKwf3i
KiHZ9U2e9HRIbcQwClnAQZqWjIAYSl5sOhgDbEWQBA/2iF05bYIREe40Nk7H
9R04YuJLOd2ujBz58joUwq8S8p1xFxpMTrfdFQnB3IFbn9Uy4XE5XEbw13so
3t3wKSsyOdMWtejn78Ifgc/XoUc8ezg+T24wYM5BRhcdPj7vqqi4CSBIiKpI
9Tta1eCjbvM0YPhz5pOpXPDGRt8YjZZbvEYBao2sgCWBaEl0js1nm7d5JoHV
9qkhiGyjvUhFHMMY4kYUUYWBqliUhyBoFAhGPVkxtFQtVSHswK0RPpWh66xf
GWGQWWktjYGptmumnHWOj5F0vPtUMOLVOuJYvt5N0Zy4Pc84lKVaQfMcoWTx
qbW4ziWS78BIepo05B8mashvTlET13BJbfMcQ2+pTQjStDHDP2Ho8ACPgYPg
igVWUTFP15fbgXDnoDqpC7phbCaCFs+VO0IKIjGlnpsOFyJIkLYfeh5bwkuV
IhIgdgFkgKo/SQl/lJuwsTAqLwRE6/E8Au71i7OkwhVpgS4wy36yfHpQqvVh
lP3xzDo7Er2lLnOGDkOuWfu6f6QeFwk7yxltatxQSI0Di+iH2aUgiJnuRmnb
RD7brCuWDalj8UFhGETY7nTkm1ppH2JuXE4RmX5KHXGsMoeb6GUjdpwHLZNu
tYBvOLNqSAOtNpToAXS5rfeP7MJtgXJu5fmHpgkao394eP32/c9nV1+/Aj/5
YNyKWJocARpiKwnUBoRJUJjPtOug9iQ+ZJfcEY62DpFix7OE0t34YMIg3h1f
37w/fX+BEl8TA+CcJFvHuLEBgCLC8HBZKrRcvc5LpO3bSraNUOL4iMQs38Zr
PDvUnUmo6B3o0uUIRdHG2cSTwbnE60BUDdQ7wb8woRr0akIXUYxCM2oec17p
sQ/9KcJYbwiV7DWlJMi017LYWuKHag8isAK/HsJbrFshVT/My4Dl4Eu5jNI0
zG/jmlxdniAqEPzghXl3eY6LdXkOfxrsD8EgBk+EFs+RdOoPMTfz4vIDAkIt
qwC+SP248maX0YnSW8x3M4QsfCpMx5YKG7O5qoiUE+4FHGwTTXA1hZAB41WO
1TGnAu5QaoKfw0/u2sDFbbGZrA1mqfeRe7k8++DN5WVyffreO628EuFdgXj9
2c31efLu7CQRGD1M0p3zCrJBg5Bt9C57yj8LW2KL8o/kqfd44rCm6sERBm1p
h2Xi4A40sfxRpJNHEUJilKc1pJCg+QvwHYZqI6eESlO4BkbNYJHGb+LqeJ5J
lCTPutXm/PT2anMG6oY8a5DRc2qp6Y45cJF+U/ap6y+oVijU+4zW2wvnXezs
tbPtwL0fRSAK8BHtkmhLw24VaftsbMU0Nzx0ydVyYW+uiu5RTMpN3ybsu3I9
hnhC/hVOaAMzU5IJKC0Rsy9AMOEJoIs61n7juqtFabZxeCEr7cEbycmpm3O3
kV4Fb5dacIGCnBLeMi+05cB3pb7fGuQzycGuxHdCm6VH9Rl0PsKqsEX8L8/t
fs4gIC3oiVb/M0T4Em1UBJScZKbYjdvhkFi17KSM+lwZoWki7qY6jkjT70Be
3vHUyc4JVPVQ5Gx45O6raA1C/rnWYDE+wew3nXIpQE0XOTagtdRumFxG2ktN
TXNN/62csqUnWxZ2vdw2c100xJpzGF6+6gRl9dnZBRi9X+PJKbbIunHd5sqb
56pUMBY/aVvyKm5y/OaQaq1vOT7vd9T3+yxDZZiobgBHujp9dxw/9HAzVAqJ
WWQbZOwcn/ssePbQtjAH2yYifI2NAdK8sAyn8ASJ1DjkoFQzK0cB4n6mmAW7
65aTAs3gglCHHfWkc+s4xLIgZNZLhD9Fw6daJSfw+ElZtdS/rggG5zeJWNWs
4ZrCO+Fxw87HEe/wrAPGPpshZnbayii7+pMOKKvJCDmW3urACKtsig3fEFtR
+/FaVDTABiN7ZCwlqwuBTbh6oyRHoOzwvg/XZyfH12fHF8dv/3J9DkoJcV18
IBt1FATmKOxI8QEpPI/YAFUuYhrGAG8ro7QmlF5b7Uj2P/7vO3rGhnD8sbSh
ZiflMbVM6Pgnzxj8M//kGTfYkJEO2Rd+v6RmUCP0hP64En3vf+BfO6Hzxm6y
Npcv1NZpUsAvl6EB1RdNeMY/+PGSnGNz+WfX9D91Y7yb8MSM9ddXx+/Ofn5/
9dM1nb+3xxdvPhy/ObvGc0lM8r/nZPw/4PM/vD2/eJPcnJ38ePH+7fs352cc
SNUJrFPZf9vJ8L+P59fn7y92rnc3TuM/czKdaSueuWn+SkcDwXARZa1gVua/
/2F9+P/+B+W21ICb4x8WW6Pa5Glq5ig3XmUkZ3HQU5coMngEjY0syM6d1xeR
T6XuVAYRnEr5pIhrTeInDr6YYh/0En6gGHP+1rWmaPiE8FxJV5EQqug31nLU
F7NbToJ0VHLQhbZo7A71lzFkZW2X9nx/QW1GHNJsGPKa+/EIfgy3viXxGDaE
Y531JtX5ADSNlz34sT94ij8OBof84zn/eNHjyFOPdWgeFGlbA6WIx8+op45R
PpHKRiqXi5AfuMEBIVCFXCZeKV4DEaIGBx3dLUkJVWZ1+nyrNUm0lQrvoA6N
+MiOE5myLwp7P3TQpt3w+8hQWlPH1GeFVisrrMBZoholCq2AkFvvRNJXAvy+
9N/AQixpYESpvWRkhYLBx/rAarsmqf/5PaT0oucpCqiGGjP2GIWRf+zzj+dM
WE+ZsPa7COv3STVPcBybIxeaLWS72WbIraAmR5gNx+rgYOtEjCufQJHTdk9E
N9AKXelYsxZylIY2lmah31tlRk88IWwQ7bpUeS3ZmITU+ajRivPEuZ4SPma/
oM3nBK2LkvBepFiNe2swSol2cl2HPiGHf+yaF+u44LC+oeV2UIPrepMS7A5s
z+Ov8s2R/3HKe8ok94zZlvCyff5xYJztGV+JP57xD/nwJZPqU/7xjH8c8o/n
PW6R0eMacf6xzz/kw0Oj5kN+7aHecIAPO+S3K4kfDrq6hBI+ANVIqtj1PUCB
jvvoJ/W16GsL0ajBOEWsMyotd7lY7JHsKMBm0g8tF4K1pH0Rgpc24b359z90
aP7+6Mnp0qYDlcB7WcVGKIqsl7cEPVurwybh42+KPjxWr7G2D7U4RpiVp6N0
0XCrdrIMgpsfvuSEQAcGZQkCZsOir4FnimDurH+xmanvfZwEiQL3B/H40TRh
48JPgI9MaE3L1scCmP0QfXlSNi8SQEbHJffBrc8iysGW/J4x10T3+0z+B/zj
hRG8Y9gHTLiHQrh+imRzBbvpkXlqh/eelob2zHjuaVBQrS+NjuXSFsYLqd83
U+MMcpj3ed77Ojfqn9OaWzAigy3oJ4hdDRHLzUHxe5zZCL43NDYoRDHxMp7b
wYWQlOHCss94RVdPhNIkMMDjFvhzbkFHPt/fuz5PmVc+ZV75lFfrKSuDT1kZ
NLrYN7o45CuVrz1rLWFkeosBvYFGXOsy6/mjrbXkzFMEhzM8KKCGGlqfPCFh
Tawzbk/yrLDmtilncJSKf2ZxvucFOIyky7NInjyPBMkBy4yngb6ecR6Qpmzh
evgz/vBtnQ3/Gh98sLq8yO9JIBGkL6eXi5zn9Ob/+I95PgJGd1t+zurtbW7r
QE0nRqEZoL6cTxynWFDXZmWE3E8aVpMb0xoWoJRgjoJC0AsYCqhQR0WuoYjX
cdtRiflxEnGjOFg+Jh8Xdx6MVgMVcdUW3LScPkEHR9X10HMec4+sGVnK3SND
w7FIgcprKyyF80MX9F2AVJNAilVA4ZSmabSqw2q1aFDLW0yDd5kEaTGTLq2K
sBIDncWZ89I0F94moapojKEtLJfIFsmygBvw1Yhlof0mufGJJoZbQ2ztgs1p
tNqQMPiep+Uc/lehKZzIU+noCBizto/BV7PZi4dRxTb1dXMGMLdd9pExIZvW
eLUv2JTRWEOCYI6l3AiQTaqQ682X4+k2mGJK7YQdpVZWmr9vhB0RM6rGxSoQ
kEMObq2kVuuj9dQeV1gZTNcOD8PzJY1qaLfnKWKlYETPsgXqAJ/BDRXzJpmU
DXuRYasIvVVC5nHiYlwzXnIfHEwdTJsGu+DdZUOFcEYMeYK4BfL/UVsBusKG
MOLwCkRbx1xPjiQII2BK4l2i+DcidmjDXWwfB5olN13W05pZlyZJsw+wmQIm
EF7ZKhKhF1B8Gl8nZSGfqcvOzKAOGQ6MMxV8ymbJUT5KA8lSzshOo34qOqcZ
xrs1iaxWPJoVKbORbS+nQu9r8SPFTEpd7Xyb+7j2uBjymd1RWqTrk0v5uD49
WaSWS+f5/xq7uqa2kSD4zq/QI1QZ32/wBXKBSiUU5u7qHoUl2yqERUlWgHPl
v990z8x+yCZ1Lwk4jr3and2ZnenpJsdf5gllTlxn0zEJYdvnRkJ7NLSXa30O
8H3gMhtAC8myiSzL4DZXOyi1W7ulXnVLs7F4OLFcDoUWX3xtUqoiL+PMFVcC
YxivL5R1So5v+Qw71Wfa6w5xLbQNvNQho1Fqc8AlVkLWfaMA0YTSzw5Xbzkw
7lgg6AZtFGfvQ6kX+rIlrNAOwnA/2tXY3SgUqZD4ummt1vUy9pjledKMJwa3
6Q31mTmjcETw+EmOEXJIqvRXQ4GpNeHkHBBRNrUGbdEzp1KkKSw9EKgAN3E4
PHxdLv+8/+v6H1Au4AqpjSXyMvDpd19vHuTHnz+Tbefrmg58EhUgp/Tscauc
JpsOv+AzEbfu6lCu5PTFFYA5xJlGLapO5kT3AQic6vSINZncvlYuOFbR4rPn
rYTpmKGMzZ4brgmzg/Fghj3/W/fdZehexAx2az2/uW0Kdt/5YTM1VJTcjFIU
66b84u6+s20m419cydwAT3elk41AomxwGQh4oWQTa9hjhyuPcbDoO1/aB5OX
j2+qeaqW9Ch/vDYVmDTlyJcbv/iS0gvcivQMJcu2fiueasKOS5U9m599V1TN
LLEENTsJsmwGEvt0xMrgrULJK9apQT6w/+slTngIQKFDusDbdpRNqTTNIPSF
KJ0aH81bOu3OrO2JBFZ526GzraDRUBXesBp7XxH9chA6uchynmMLnZwnneix
tnLeSWEHp5HMq+PWD3b6JvfdUS2VWJF0G+3eHZZLphtsxBk6kUp1A6y26Flu
nEjJTfo8+Zl64TMTdudRfHrf42Mv7MlgcviBQzeN0TeiGCHROpowQtIwF0Zj
X6y7vfsRdBmmsyeBEbDlDmMJ/hLrRlnql7K30+88h3pRfIZVeAf8XcxiHYAy
5I1XXNJ2AxkhjPao2sNmvmx43uTmSpCIXJr1e+4ilzHQ+oWleKEgKripgYRN
E7eKJXuyOk/u6OlVyyS5dww1TBCGZpAhJQag6VQR2o6j8OZJ9EMyX2a+abd9
vZEp2yPLlxE+NqpHQBGldBd1ftDg1+cAGLOPaQjctYS6e6u2fIVoSfAfvJbQ
4FP8PWPnxQ0WyNVVswGZ7pyYa6rZo3oG2AB6qZuCYwyjZNi9wDkcT7FczEp1
MDX4+tE91QFZcwJ0w1KUXJwKDx11Zyd1Krnw1ceInWDX484fdJoiBMGtofeS
vKJFvoE0M/CGNQnL2BBxfvrmwANb7g0RbqW3hHv5SN2WUsuLb4tJYuPs228L
/pu8vGpHRGiaQa661fisTocNVeT2c0SxQkbroG/KGc+uAOpWbZA8regDTNlq
3biwaUZ36eFfyFo8YhcFMaASnNt0LBalwiEcFyvqmASZQ/2i0hLcCCWBKqAz
48MES9OaLdpKtLxJVcogejcU54eDvHQdX1H5N41fyOinNIr+zqxfDG9FK22i
s5jXBifaYIfDScVrfEx0e/EhNPw+xtZ53ycoi9t3vaJmVNzr9NbXZPcbm3d6
Kn30JNMrIxGj+l21l7hvVSYkEp4ZwWzWrBRpvZN+idc6qhpVidCMXsyaIWJY
A0/58YNaUvd5bE1/vFcvUykG8nQtZtLHnYhWq0ieQrS9l17CwRcPQ9NBzimy
Iv4mRLcWiTeD5YUsP9BN8GmdsY5kkpBxTZXrVdvaGPfKHXpXvgzbbq85rwiF
jSfI+pQRvBHbC9b5GzblGbtbVU+Ko0ynuZDWqkXW/NK0ZDMadpaJyCb5+K5/
s7jT7F2wTZfTE6H5kjJArFSXLlQX912akt91Ln9haiaXYkhITm6Vmx5B7Izu
p22bDQcbrSDUmWKhloEe1D937LsJzQTn2imp3TMXymx26rxjL/IxElZPXaP/
SHIrqR64gwkdbPgBRJAXyd46WQwBsTIFKS0H19Yfyp3QoP3dMI5GHViurI1D
biWzE9tYySsA47deEsYvcYMO4OnUJspZ0kODwcoDN86TjB5hBnjD+Dio4Fso
FQEoXiziPuBBoXABbS4ejEeZiXLexcrdU3EN5uy/y83OWqySL+dtxHrGP4h+
MAG3426zLYsvnWWdtyp+LDagYNoOHnX0x/FcraeX2QMbsKLB8XETA+jJ8BRQ
aLYiVhZAfwhmHdKWkuQD5ycmwuuv+YR8km/eylWpWMri7Le4E1S9LOpVKfNS
fO/B+3u3bdriWvZLW4sXXO5HdLx9kt9nxa08ei+3yS+yRx66uufV+ho3hL06
j1uEgH33uhJP7DrUOIfYmVH2La5iRCAwTaxm7U8hVzAJQHbFXQ3PoFaBp7y5
f/gMa2r8w+yr5Novlv4ZBZ6uiW8PZnRzv/zD/sf87D/enaJ6z3gBAA== same for everyone.
-->
</rfc>