<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.24 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-various-eimpact-arch-considerations-00" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.0 -->
  <front>
    <title abbrev="Sustainable Internet Architecture">Architectural Considerations for Environmentally Sustainable Internet Technology</title>
    <seriesInfo name="Internet-Draft" value="draft-various-eimpact-arch-considerations-00"/>
    <author fullname="Michael Welzl">
      <organization>University of Oslo</organization>
      <address>
        <email>michawe@ifi.uio.no</email>
      </address>
    </author>
    <author fullname="Emile Stephan">
      <organization>Orange</organization>
      <address>
        <email>emile.stephan@orange.com</email>
      </address>
    </author>
    <author fullname="Eve Schooler">
      <organization>University of Oxford</organization>
      <address>
        <email>eve.schooler@gmail.com</email>
      </address>
    </author>
    <author fullname="Sebastien Rumley">
      <organization>HES-SO</organization>
      <address>
        <email>sebastien.rumley@hes-so.ch</email>
      </address>
    </author>
    <author fullname="Ali Rezaki">
      <organization>Nokia</organization>
      <address>
        <email>ali.rezaki@nokia.com</email>
      </address>
    </author>
    <author fullname="Jukka Manner">
      <organization>Aalto University</organization>
      <address>
        <email>jukka.manner@aalto.fi</email>
      </address>
    </author>
    <author fullname="Carlos Pignataro">
      <organization>Blue Fern Consulting</organization>
      <address>
        <email>cpignata@gmail.com</email>
      </address>
    </author>
    <author fullname="Marisol Palmero">
      <organization>Cisco</organization>
      <address>
        <email>mpalmero@cisco.com</email>
      </address>
    </author>
    <author fullname="Jan Lindblad">
      <organization>All For Eco</organization>
      <address>
        <email>jan.lindblad+ietf@for.eco</email>
      </address>
    </author>
    <author fullname="Suresh Krishnan">
      <organization>Cisco</organization>
      <address>
        <email>sureshk@cisco.com</email>
      </address>
    </author>
    <author fullname="Ari Keränen">
      <organization>Ericsson</organization>
      <address>
        <email>ari.keranen@ericsson.com</email>
      </address>
    </author>
    <author fullname="Hesham ElBakoury">
      <organization/>
      <address>
        <email>helbakoury@gmail.com</email>
      </address>
    </author>
    <author fullname="Luis M. Contreras">
      <organization>Telefonica</organization>
      <address>
        <email>contreras.ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Alexander Clemm">
      <organization>Independent</organization>
      <address>
        <email>ludwig@clemm.org</email>
      </address>
    </author>
    <author fullname="Jari Arkko">
      <organization>Ericsson</organization>
      <address>
        <email>jari.arkko@gmail.com</email>
      </address>
    </author>
    <date year="2025" month="March" day="03"/>
    <keyword>next generation</keyword>
    <keyword>unicorn</keyword>
    <keyword>sparkling distributed ledger</keyword>
    <abstract>
      <?line 207?>

<t>This document discusses protocol and network architecture aspects that
may have an impact on the sustainability of network technology. The
focus is on providing guidelines that can be helpful for protocol
designers and network architects, where such guidelines can be given.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://jariarkko.github.io/draft-eimpact-arch-considerations/draft-eimpact-arch-considerations.html"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-various-eimpact-arch-considerations/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/jariarkko/draft-eimpact-arch-considerations"/>.</t>
    </note>
  </front>
  <middle>
    <?line 214?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Environmental sustainability is an important consideration in networking. Both for
ensuring that networking technology can enable societies to operate in
an environmentally sustainable manner and that the networks themselves are environmentally sustainable.</t>
      <t>This document discusses protocol and network architecture aspects that
may have an impact on the environmental sustainability of network technology. For brevity, we will use the term sustainability to refer to environmental sustainability. We do note that sustainability as a term is widely used to refer to different notions of sustainability, and the most well-known larger definition of sustainability can be seen from the United Nations Sustainable Development Goals (UN SDG) <xref target="UNSDG"/>.</t>
      <t>Sustainability impact and emissions from networking comes from three primary categories: hardware manufacturing, direct energy usage and construction work.  The last category is out of scope of this document because networking has limited means to impact construction work
itself.  The manufacturing of networking hardware, both for fixed and wireless networks, is a significant source of emissions, and recycling of ICT equipment is still limited.  Direct energy usage of networking and the source of the energy have been the primary concerns, but as the world moves towards greener energy production, the relative negative impact of the emissions from manufacturing becomes more prominent.</t>
      <t>When good design and architecture can improve the sustainability of
networks, they should certainly be applied to designing new protocols
and building networks. Intuitively, protocol and network architecture choices can have an impact on sustainability.  At the very least the right design and architecture
can make it possible to have a positive impact, but of course the
architecture alone is not enough.  The possibilities offered by the
architecture need to be realized by implementations and practical
deployments.</t>
      <t>To give an example of an architectural aspect that potentially has a
sustainability impact, enabling the collection of information (e.g.,
energy consumption) and then using that information to make smarter
decisions is one.  For instance, understanding power consumption of
individual nodes can be valuable input to future purchasing decisions
or development efforts to reduce the power consumption.  Yet, as
data collection is often rather easy, we should not overdo it in such
a way that it leads to accumulation of dark data (i.e. data that is collected and stored, but never used).  All data collection consumes processing power,
network resources and storage space, and this can in turn increase the emissions
from the network.</t>
      <t>Other architectural examples include making it possible to scale
resources or resource selection processes performed in a
sustainability-aware fashion. The use of communication primitives that
maximize utility in a given problem (e.g., using multicast) or the use of
technologies that reduce the number or size of messages needed for a
given task (e.g., binary encoding instead of textual) are some further
examples.</t>
      <t>Of course, some of these aspects may have a major impact on
sustainability, where others may only have a minor effect.  There are
also tradeoffs, such as side-effects of architectural choices, e.g.,
dynamic scaling of a router network potentially impacting jitter, or
putting cellular base stations to sleep and activating them as capacity needs grow may introduce a delay in matching the needs of the data flows.</t>
      <t>The document is intended to help engineering efforts in the IETF,
provide operational guidance in the operator community, as well as to point to potential research directions in the IRTF.</t>
      <t>The scope of the document is advice on Internet and protocol
architecture, such as what architecture or capabilities new protocol
designs or features should have, what kind of operational network
architectures should be deployed, and how all of these can be designed
to best address sustainability concerns.
The focus of this document is to provide actionable design advice to protocol designers. This document therefore
addresses one aspect in the architecture question, and does not claim
to cover the topic exhaustively.</t>
      <t>This document is also not focused on general issues around environmental sustainability,
except those that pertain to architecture or significant protocol
features.</t>
      <t>It is to be noted that networks themselves are a service, a tool, for all the
applications and services on the Internet. Networks connect data,
people and services. The increase in networking and size of the
Internet is driven by these applications and the usage. Therefore the
emissions from networking are tied to the applications and the data
they consume; with less applications or data, the Internet would have less
hardware and less energy usage. The goals of this document are not to
instruct application and service developers to choose what
applications are worthwhile or how much content is sent. There are
many forums and parties whose mission is to help these developers to
implement more sustainable services, such as, the Green Software
Foundation, the Green Web Foundation, Greening of Streaming, to name a
few.</t>
    </section>
    <section anchor="potential-architectural-aspects">
      <name>Potential Architectural Aspects</name>
      <t>This section presents architectural and protocol design aspects that can have an impact on the sustainability of networking. For each topic, we provide an overview, the motivation for why it would be important to consider for more sustainable networking, an analysis and recommendations for future networking professionals.</t>
      <section anchor="measurement">
        <name>Measurement</name>
        <t>It is essential to understand the current state of affairs before any improvements can be made. i.e. Some levels of measurements are necessary for starting to improve sustainability. This is
particularly the case when looking at the systems as a whole in
post-analysis. As discussed earlier, this level of measurements is
useful input for further actions, such as deciding what parts of the
network need to be targeted for further improvement.</t>
        <t>But measurements may also be useful for some dynamic situations
where power-saving decisions, for instance, depend on knowing the
relative power consumption of different activities, such as when a
power-off decision involves understanding the relative savings during
the shutdown period vs. the power cost of shutdown and startup procedures,
or the possible need to reconfigure other nodes in the network due
to the shutdown.</t>
        <section anchor="motivation">
          <name>Motivation</name>
          <t>Measurements are a necessary mechanism for both post-analysis and
potentially for some of the dynamic decisions taken by systems. Without
measurements of any kind, it is impossible to assess if the networks
are functioning correctly. It is impossible to know if the system is
efficient by comparing it against a baseline model. It is also
impossible to check that changes aiming at optimizing something are
indeed valuable.</t>
          <t>For instance, while electricity providers can make information about power
usage available, this is only done at the aggregate level. Without
per-device data about power usage, there would be limited basis for
deciding where power is actually consumed and consequently, what
improvements are most useful.</t>
          <t>At the same time, it is not possible to measure
everything. Furthermore, any measurement must be validated. Relevance
of measurements must be periodically assessed, e.g., with comparisons between measurements within a network and the aggregate numbers from the electricity provider.</t>
          <t>Finally, measurements made in the field must be collected and organized to allow
later retrieval.</t>
        </section>
        <section anchor="analysis">
          <name>Analysis</name>
          <t>While the simplest forms of sustainability-related measurements are
about power, there's clearly room for other measurements and other
information as well. To begin with, power consumption by itself may not be what
matters most for sustainability, as the source of the power may be
equally important in terms of determining the actual carbon footprint.</t>
          <t>Secondly, for many classes of devices the embedded carbon aspects or
use of raw materials may be a significant sustainability issue. See
also Section 2.2.</t>
          <t>Third, power or energy measurements alone are of meager use if the
cause of the consumption is not measured as well. Any power/energy
measurement should occur alongside other measurements that can be used to determine energy efficiency. Hence a sound measurement
architecture implies that a prior existence of an energy efficiency
framework of some kind.</t>
          <t>But when it comes to energy consumption, as noted the aggregate
information is often typically available, and it's not particularly
hard to measure the energy consumption of individual network devices
either.  Still, there are a number of desirable use cases where the
measurement situation needs to improve.</t>
          <section anchor="measuring-power-efficiency">
            <name>Measuring Power Efficiency</name>
            <t>When assessing the power consumption (Scope 2) of an IT-organization,
emission accountants are generally looking for a metric of the
delivered value per unit of energy.</t>
            <t>A commonly used method is to equate the delivered value with the
number of bits sent or received, or to the communication capacity made
available when there's a need for it. The latter is important, as
often communication networks have requirements to be able to send
messages when there's a need for it, e.g., for emergency communications, not
that those messages are always being sent.</t>
          </section>
        </section>
        <section anchor="recommendation">
          <name>Recommendation</name>
          <t>Ongoing work at the IETF's GREEN working group is already targeted at improving
existing energy consumption metrics and frameworks but some further
considerations may apply. In order to meet the needs discussed above, the following architectural design principles
are proposed.</t>
          <section anchor="generality">
            <name>Generality</name>
            <t>We recommend that any measurement framework or sustainability-related
information sharing mechanism be designed to share different types of
information and not limited to a single metric such as power consumption.
Similarly, the granularity of data collection needs to be configurable so that the metrics collected can be as fine-grained or as aggregated as needed in order to identify potential areas of improvement.</t>
          </section>
          <section anchor="collect-metrics-from-existing-equipment">
            <name>Collect Metrics from Existing Equipment</name>
            <t>Since the need to deliver on the use cases described is urgent, the
industry has to accomodate the capabilities (and limitations) of existing
equipment in the field for collecting metrics.</t>
            <t>It is recommended to have a plug-in architecture with modules that can
work with (read from and control) devices of any kind, including
traditional networking hardware devices, cooling systems, software
stacks, and occasionally static datasheets.</t>
          </section>
          <section anchor="content-declaration-for-all-collected-metrics">
            <name>Content Declaration for all Collected Metrics</name>
            <t>A warehouse filled with data collected from diverse sources is useless
without proper labeling.  Hence, these is a need to create metadata that describes the
collected data.  (e.g. What are the source(s)?  What measurement units are used?
Precision?  What is included/excluded in these numbers?)</t>
            <t>The metadata itself must also have a formal description.  e.g. Use YANG for
the metadata schema.  Keep the metadata attached to the dataflow it
describes, so that the relation is clear to each component that has
anything to do with it, including components added by other
organizations at a later point in time.</t>
          </section>
          <section anchor="collection-aggregation-processing-display-decisions">
            <name>Collection, Aggregation, Processing, Display, Decisions</name>
            <t>The collected data passes through a pipeline from collection to
decisions. By processing we mean steps to reshape the data to
match further aggregation and processing steps, such as unit
conversions, sample frequency alignment, filtering, etc.</t>
            <t>Separate these architectural roles into separate modules in
order to enable reuse, modular development and a transparent,
configurable pipeline.</t>
          </section>
          <section anchor="configurable-pipeline-for-reuse-and-transparency">
            <name>Configurable Pipeline for Reuse and Transparency</name>
            <t>Let the pipeline connections between the components be driven by
configuration rather than hard coded.  This enables reconfiguration of
the processing pipeline over time, and perhaps more importantly,
transparency into what stages the data pass through, even without
access to or understanding of the source code of the entire system.</t>
          </section>
          <section anchor="design-together-with-the-users">
            <name>Design Together with the Users</name>
            <t>Every system should be designed involving some of its target users.
In order for delivered metrics to be of any value, the target audience
needs to be aware of their existence, be able to interpret them and
understand how they can be used in their professional context.</t>
            <t>There are many target user groups for the information produced.
Some examples are network designers/engineers, scientists, operations teams and IT-development organizations.  One critical group that is often overlooked is
the sustainability assessment experts.  If they are not aware, don't
understand or don't care about the produced sustainability metrics,
the value of this work would be greatly diminished.</t>
          </section>
        </section>
      </section>
      <section anchor="modeling">
        <name>Modeling</name>
        <t>The paucity of up-to-date information on equipment and system
parameters, especially power consumption and maximum throughput, makes
estimating the power consumption and energy efficiency of these
systems extremely challenging. In addition the rapid evolution of
technology and products in ICT makes the estimation quickly outdated
and possibly inaccurate. In almost all cases physical measurement has
to be replaced by partial measurement and mathematical modeling.</t>
        <section anchor="motivation-1">
          <name>Motivation</name>
          <t>Where power optimization choices are made, accurate information is required to decide the right choice. Modeling instead of measurements may have to be used in some cases.</t>
        </section>
        <section anchor="analysis-1">
          <name>Analysis</name>
          <t>To date, two approaches to network power modeling are accepted as
providing a realistic estimate of network power consumption. These
approaches are referred to as "bottom-up" and "top-down".  The paper
<xref target="Unifying"/> surveys both approaches and provide a new approach which
unifies both of them. The unified approach is used to estimate the
power consumption of access, aggregation and core networks.</t>
          <t>The paper <xref target="Modeling"/> provides a
model for IP Routers and the routers of other future Internet
architectures (FIA) such as SCION and NEBULA. They use a generic model
which captures the commonalities of IP router as well as the
peculiarities of FIA routers. They conduct a large-scale simulation
based on this router model to estimate the power consumption for
different network architectures.</t>
          <t>Since routers and other network devices and functions can be
virtualized, this article (1) provides comprehensive "graphical,
analytical survey of the literature, over the period 2010–2020, on the
measurement of power consumption and relevant power models of virtual
entities as they apply to the telco cloud." This paper A Methodology
and Testbed to Develop an Energy Model for 5G Virtualized RANs IEEE
Conference Publication IEEE Xplore got best paper award for GreenNet
2024, but I am not sure if we are interested to model 5G vRAN.</t>
          <t>There is a plethora of publications on modeling communication networks
and DC computing.</t>
          <section anchor="customer-attribution">
            <name>Customer Attribution</name>
            <t>When organizations assess their Scope 3 emissions, they need to sum up
their share of emissions from all their suppliers, one of which for
example, might be a cloud hosting service.  In order for the supplier
to provide an emission share value back to the customer, the provider
needs to develop a mechanism for attribution.</t>
            <t>A significant challenge in accurately assessing Scope 3 emissions is
avoiding Double Counting, where the same emission is reported by
multiple entities. According to the GHG Protocol best practices, it is
crucial to establish clear guidelines and agreements between suppliers
and customers to ensure that emissions are attributed correctly and
not counted multiple times. This requires transparent communication
and precise emission reporting standards to ensure that all parties
involved have a consistent understanding of which emissions belong to
which organization.</t>
            <t>By addressing the Double Counting issue, companies can achieve more
accurate and reliable Scope 3 emissions assessments, thereby
contributing to better overall sustainability reporting and
improvement efforts.</t>
          </section>
          <section anchor="baselining-and-benchmarking">
            <name>Baselining and Benchmarking</name>
            <t>Establishing a baseline is a fundamental step in the process of
improving energy efficiency and sustainability of network
technology. Baselining involves establishing a reference point of
typical energy usage, which is crucial for identifying inefficiencies
and measuring improvements over time. In this step, the controller
uses only the collected data from datasheets and other reliable
sources.</t>
            <t>By establishing a baseline and using benchmarking, organizations can
determine if their networking equipment is performing normally or if
it is deviating from expected performance. This is the first step in identifying and guiding necessary
improvements. Benchmarking involves collecting performance
measurements of networking equipment under controlled 
conditions. This process helps establish standardized performance
metrics, allowing for comparison against baselines collected during
regular operational conditions.</t>
            <t>The initial measurement of networking equipment's energy efficiency
and performance, known as Baselining, should be coordinated with
vendor specifications and industry standards to understand what is
considered normal or optimal performance. For example, if the baseline
indicates that your switches operate at 5 Gbps per watt, while vendor
specifications suggest 8 Gbps per watt and the industry standard is 10
Gbps per watt, actions should be taken to implement energy-saving
measures and upgrades. Continuously tracking subsequent measurements can reveal if
efficiency improves towards the benchmark of 8-10 Gbps per watt.</t>
            <t>This practice ensures that any improvements can be quantifiably
tracked over time, providing a clear measure of the effectiveness of
the implemented changes and guiding further enhancements in network
sustainability.</t>
            <t>See also <xref target="Baseline"/> and <xref target="BenchmarkingFramework"/>.</t>
          </section>
        </section>
        <section anchor="recommendation-1">
          <name>Recommendation</name>
          <t>Even though baselining is essential in identifying potential areas of improvement and tracking progress, it is still to be determined to what extent we need to work on modeling networks and devices in the architecture.</t>
        </section>
      </section>
      <section anchor="dynscale">
        <name>Dynamic Scaling</name>
        <t>Dynamic scaling is the ability to adjust resources according to demand, and possibly turn some of
them off during periods of low usage. Examples include the set of
servers needed for a service, how many duplicate links are needed to
carry high-volume traffic, whether one needs all base stations with
overlapping coverage areas to be on, etc.</t>
        <t>Networks and communications are also critical functions of the modern
digital society. The reliability of individual networking links or
devices cannot always be guaranteed. As a result, various levels and forms of
resiliency are often needed, for instance through redundancy. Yet,
there is a question on how much redundancy is needed and how quickly a
backup or resource increase can be activated due to increased demand.</t>
        <section anchor="motivation-2">
          <name>Motivation</name>
          <t>Outside of implementation improvements, dynamic scaling is potentially the
most promising method for reducing power consumption related
environmental impacts. Scaling can happen on a device-level (increasing performance as traffic levels grow) or a network segment level (increasing the number of active links or cellular base stations).</t>
          <t>Considering current fixed networking hardware, dynamic scaling might not have an impact in
situations where there's only a single router or server
serving a particular route, area, or function. Current routers and switches exhibit limited potential dynamic scaling because the focus is on high performance and a stable connectivity. There have been some recent improvements on this front as well. e.g. Energy-Efficient Ethernet (EEE) is a good example of a networking-level specification to lower energy consumption in idle mode. EEE has limited impact on a network that has continuous traffic.</t>
          <t>Resiliency can be implemented within a single router as well, e.g. as a backup power supply, between routers and switches as multiple links between the same nodes, having different links between two end points, overlapping cellular coverage, etc. All these necessarily add more hardware to provide the same exact service. Some of that hardware can be fully operational at all times and used to serve the traffic, while other links may be in hot or cold standby depending on the use case.</t>
          <t>Cellular networks are typically built with
significant overlap in coverage areas of multiple base stations. Demand and business reasons dictate
the design of the coverage, and regulations might dictate how reliable
the cellular service should be. There is extensive work world-wide to
optimize the operation of this overlapping coverage, e.g. by turning down
some sites at night time when traffic volumes are low. A cellular
basestation site can consume anything from a few kWh to ten or more
kWh per provider. Modern cellular base stations do implement numerous
features to scale the energy consumption. In general, cellular base
stations have a base energy consumption and traffic-dependent
consumption, a somewhat similar behavior to what we can observe in modern CPUs.</t>
          <t>On the network level, most large systems have significant amount of redundancy and spare
capacity. Where such capacity can be turned on or off to match the
actual need at a given time, significant reductions in power consumption
can be achieved.</t>
        </section>
        <section anchor="analysis-2">
          <name>Analysis</name>
          <t>Dynamic scaling could be seen as either an alternative or complementary to load stabilization, e.g., via "peak shaving". Perhaps the most realistic angle is that both are likely needed.</t>
          <t>The most rudimentary approach to dynamic scaling is just turning some resources off. However this may not be sufficient, and a more graceful/engineered approach potentially yields better results.</t>
          <t>Network architects need to understand the impacts of scaling changes on users and traffic. These may include the fate of ongoing sessions, latency/jitter, packets in flight, or running processes, attempts to contact resources that are no longer present, and the time it takes for the network to converge to its new state.</t>
          <t>Dynamic scaling requires an understanding of load levels for the
network, so information collection is required. It also requires
understanding the power, time and other costs of making changes. (See
<xref target="I-D.pignataro-enviro-sustainability-architecture"/> for discussion of
tradeoffs and multi-objective optimization.) Understanding the resiliency requirements for a network or a piece
  of equipment is also important for the optimal control of
  resiliency, e.g., as an input to decisions on how many instances of
  replicated services need to be run and where.</t>
          <t>Some of the strategies that are useful in implementing a well working dynamic scaling include:</t>
          <ul spacing="normal">
            <li>
              <t>Matching the currently used resources to the actual need, be it
about traffic demand or resiliency. One way to do this is to use of
power-proportional underlying technologies, such as chipsets or
transmission technologies. And where this is not sufficient, the
ability to turn components/systems on and off is an alternative
strategy.</t>
            </li>
            <li>
              <t>Using load adaptive techniques allows the capacity of the nodes to
be dynamically adjusted according to the demand. Examples include
Adaptive Link Rate (ALR), which dynamically adapts the link rate to
suit traffic demand or power off links in Link Aggregation based on
traffic demand which is empirically estimated based on traffic
arrival. LACP (Link Aggregation Control Protocol) defined in IEEE
802.1AX <xref target="LinkAggregation"/> can be modified to power off links in an
aggregation if they are not needed.</t>
            </li>
            <li>
              <t>Ability to enter "no new work" mode for equipment, to enable some resources to be eventually released/turned off.</t>
            </li>
            <li>
              <t>Ability to move ongoing tasks off to other equipment, to prevent disruption of already started tasks.</t>
            </li>
            <li>
              <t>Ability to schedule changes in advance rather than making them abruptly, with
associated signaling exchanges and possible transient routing and
other failures. See for instance the time-variant routing work in
the IETF <xref target="RFC9657"/> <xref target="I-D.ietf-tvr-requirements"/>
                <xref target="I-D.ietf-tvr-schedule-yang"/> <xref target="I-D.ietf-tvr-alto-exposure"/>.</t>
            </li>
            <li>
              <t>Efficient propagation of changes of new routes, new set of servers, etc. as to reduce the amount of time where state is not synchronized across the network. The needs for the propagation solution needs to be driven by dynamic scaling and sustainability as well as other aspects, such as recovery from failures.</t>
            </li>
            <li>
              <t>Build mechanisms to deal with dynamic changes: Plan for dynamic set of resources, and not expect to work with a fixed set of resources.</t>
            </li>
            <li>
              <t>Dynamic scaling requires automation in most cases, e.g., to turn on
new service instances. See again <xref target="I-D.pignataro-enviro-sustainability-architecture"/> for a discussion of automation.</t>
            </li>
            <li>
              <t>Interaction with the energy grid can enable dynamic load
shifting. For instance, a demand-response technique can be used
where the system temporarily reduces its energy usage in response to
pricing signals from a smart grid. The proposed demand-response
technique involves deferring the load from elastic requests to later
time periods in order to reduce the server demand and the current
energy usage, and hence, energy costs <xref target="LoadShifting"/>.</t>
            </li>
            <li>
              <t>Energy-aware routing. This generally aims at aggregating traffic
flows over a subset of the network devices and links, allowing other
links and interconnection devices to be switched off. These
solutions shall preserve connectivity and QoS, for instance by
limiting the maximum utilization over any link, or ensuring a
minimum level of path diversity. There are also algorithms for Green
Traffic engineering. For instance <xref target="Segment"/> employs segment
routing. Experimental analysis results <xref target="Experiment"/> show that the
resource usage for SRv6 could be more than 70% lower than that of
the SPF-based forwarding, depending on the network topology.</t>
            </li>
          </ul>
        </section>
        <section anchor="recommendation-2">
          <name>Recommendation</name>
          <t>The guidelines above need to be considered specifically for each
protocol and system design. Further work in detailing this guidance
would also be useful.</t>
          <t>It is likely that there is increased attention to resiliency in the
future, given for instance the increased importance of the tasks
supported by networks or the potentially increasing frequency of
natural disasters as a result of global warming.</t>
        </section>
      </section>
      <section anchor="transport">
        <name>Transport</name>
        <t>Transport protocols are the flexible tools that make it possible for
communication flows between parties to adjust themselves to the
dynamic conditions that exist in the network at any given time:
available bandwidth, delays, congestion, the ability of a peer to send
or receive traffic, and so on. Depending on the conditions, an
individual flow may carry traffic at widely different rates, may pause
for some time, etc. Various higher-level transport solutions may also
cache or pre-fetch information.</t>
        <t>This behavior has an effect on sustainability as well, e.g., in
what periods the endpoint and network systems are active or when they
could be in reduced activity or sleep states.</t>
        <t>Cellular networks and mobile links can scale their energy usage based on load and enter a low-power state when a traffic flow ends. Thus, in theory, the faster the data is transferred, the faster the device transmission/reception functions can enter a low-power state.</t>
        <section anchor="motivation-3">
          <name>Motivation</name>
          <t>Transport behavior would have a possibility of impacting how much
downtime or sleep can be had in the communication system, either on
the end systems or routers or other equipment in between. The savings
can be significant, at least in wireless systems.</t>
          <t>Improvements through transport behavior are only useful if the
involved systems have power proportionality.</t>
        </section>
        <section anchor="analysis-3">
          <name>Analysis</name>
          <t>A critical issue is the tradeoff involved in sending traffic. As
argued in <xref target="NotTradeOff"/>, reducing
the amount of time the endpoints and the network are active can
sometimes help save energy, e.g. in case the receiver is connected
over a WiFi link. Similar logic applies for any technology that has a
certain degree of energy proportionality, e.g. cellular
communication. As a result, in general, delivering information as
rapidly as possible would appear to be desirable.</t>
          <t>On the other hand, bandwidth-intensive applications can influence
other applications or users by presenting a significant load on the
network, and consequently reducing capacity available for others, or
increasing buffering (and with it, latency) across the network
path. For an application with intermittent data transfers, such as
streaming video, this would seem to speak in favor of sustained but
lower-rate delivery instead of transmitting short high-rate bursts <xref target="Sammy"/>. However, this
is in contradiction with the energy-saving approach above. Thus, the
tradeoff is: should data be sent in a way that is "friendly" to others
(avoiding bad interference), or should it save energy by sending fast,
increasing the chance for equipment to enter a "sleep" state?</t>
          <t>At the time of writing, the common choice for video is to opt for higher
rate delivery, potentially saving energy, and possibly at the expense
of other traffic. For non-urgent data transfers, the IETF-recommended
default approach is the opposite: the LEDBAT congestion control
mechanism <xref target="RFC6817"/>, which is designed for such use, will always
"step out of the way" of other traffic, giving it a low rate when it
competes with any other traffic. Alternatively, if the goal is to
reduce energy, such traffic could be sent at a high rate, at a
strategically good moment within a longer time interval; this would
give network equipment an opportunity to enter a sleep state in the
remaining time period within the interval.</t>
          <t>Perhaps the issue is that the transport behavior (as with many other
things) needs to take into account multiple parameters. For example,
it is possible that a balanced transport algorithm would be able to
send as much as possible as soon as possible, while tracking buffer
growth from transmission delays and scaling back if there's any buffer
growth. This remains to be confirmed with experiments, however.</t>
          <t>Similarly, caching and pre-fetching designs need to take into account
not only the likelihood of having acquired the right content in memory,
but also the sustainability cost of possibly fetching too much or the
timing of those fetching operations.</t>
          <t>In general, information about the impacts of loading or not loading
the network with additional traffic, and whether a certain sending
pattern enables power savings through sleep modes, would be beneficial
for the communicating endpoints. Mechanisms for making such
information available to the endpoints would be useful.</t>
        </section>
        <section anchor="recommendation-3">
          <name>Recommendation</name>
          <t>The techniques described above have been based on theoretical analysis. There is a need for
further simulations and experiments to confirm what strategies would
provide the best end-user and energy performance. This may be work
that fits within the IRTF SUSTAIN research group.</t>
        </section>
      </section>
      <section anchor="longevity">
        <name>Equipment Longevity</name>
        <t>This section discusses the ability to extend the useful life of protocols and/or network equipment in order to amortize the embedded energy costs over a longer period, even though it may mean that the protocols/equipment may not be fully optimized for the present use. This includes devising tools to inform network administrators and their users of the potential benefits of network equipment upgrades, so that they can make better choices on what upgrades are necessary and when.</t>
        <t>It should be noted that from an environmental sustainability perspective, it may not always be the best choice to upgrade network equipment whenever slightly less power-hungry and "greener" alternatives become available. The environmental cost of amortizing the carbon embedded inside equipment over its lifetime, including the carbon associated with the manufacturing of the equipment that is to be replaced, should be taken into consideration as well.</t>
        <section anchor="motivation-4">
          <name>Motivation</name>
          <t>Embedded carbon and raw materials can be a significant part of the
overall environmental impact of systems. If this can be improved for
devices that are manufactured in large quantities, the improvements
can be significant.</t>
          <t>The more the world moves toward low-carbon energy sources, the more the manufacturing matters in the holistic view. Today there can be an order of magnitude difference in average emissions for a kWh of electricity between two countries. Thus, any estimates that seek to compare the manufacturing and use phase emissions of a network equipment would have to be calculated per country or region, and there is no universal standard for the whole planet.</t>
          <t>Long equipment lifetimes are only useful if the longer lifetimes can
be achieved without compromising other aspects of sustainability, such
as when using a high-end and power-hungry router in place of small
routers. The exact moment when a hardware change is warranted for sustainability differs between countries and regions.</t>
        </section>
        <section anchor="analysis-4">
          <name>Analysis</name>
          <t>When we engineer protocols and network equipment, we are inclined to
design them in a highly optimized manner for a very specific set of
requirements, use cases and context. While this is necessary in
certain cases (e.g. constrained nodes with limits on processing
capacity or long lived battery powered devices), there are certainly
cases where such optimized equipment is not absolutely required. Most infrastucture network nodes on the Internet utilize
only a fraction of their design capacity most of the time.</t>
          <t>Designing the equipment with an eye on longevity comes with a set of
advantages:</t>
          <ul spacing="normal">
            <li>
              <t>It allows the same equipment and protocols be reused in a different context in the future. e.g. A core router of today can become an edge router in a near future and an access router in the further future if the protocol implementations are adaptable.</t>
            </li>
            <li>
              <t>It can reduce complexity in implementations as well as in network management that are usually indicated in highly optimized systems</t>
            </li>
            <li>
              <t>It can let network equipment operate for a longer period and can reduce the frequency of hardware upgrades, in turn reducing the environmental impact associated with manufacturing, transporting, and disposing of the old/new hardware.</t>
            </li>
            <li>
              <t>One key disadvantage may be that not optimizing may result in the need for premature upgrades for capacity and this needs to be considered.</t>
            </li>
          </ul>
          <t>Hence, it is very likely that extending the life of protocols and equipment with higher flexibility could provide a better environmental benefit than tightly optimizing only for today’s uses.</t>
          <t>Another aspect that can play an important role in extending the longevity of equipment concerns software-defined networking, in the sense of designing networking equipment in such a way that new equipment capabilities and features can be introduced via software upgrades as opposed to requiring hardware replacement. This requires system architectures that incorporate the necessary infrastructure to support such upgrades in a secure manner that does not compromise equipment integrity.</t>
        </section>
        <section anchor="recommendation-4">
          <name>Recommendation</name>
          <t>The guidelines above should be considered for any new system design. If some aspect of protocol or network equipment design choice could be made more generic and flexible without a significant performance and sustainability impact, it needs to be studied in further detail. Specifically, the potential additional sustainability costs due to forgoing optimization need to be weighed against the potential savings in embedded carbon and raw material costs brought about by premature upgrades. There are also cases where equipment upgrades are done to provide better peak performance characteristics (e.g. higher advertised speeds towards consumers) and these need to be viewed as well with the same tradeoffs in mind. Finally, when designing networks it is recommended to consider whether it is possible to reuse retiring equipment in a different location or for a different function (e.g. move it to lower traffic geographies, core routers become edge/access routers etc.)</t>
        </section>
      </section>
      <section anchor="encoding">
        <name>Compact encoding</name>
        <t>This is about considering the effects encoding methods on sustainability, such as the use of binary encodings instead of text.</t>
        <section anchor="motivation-5">
          <name>Motivation</name>
          <t>Better encoding can obviously reduce the length of messages sent. It
remains a question mark how big overall impact this is, however. It
should only be performed if it gives a measurable overall impact.</t>
        </section>
        <section anchor="analysis-5">
          <name>Analysis</name>
          <t>Better encoding methods are clearly beneficial for improving the detailed-level effectiveness
of communications.</t>
          <t>The main questions are, however:</t>
          <ul spacing="normal">
            <li>
              <t>Is the effect of this is at a magnitude comparable to the other
things, or if it is just absolutely tiny? Particularly considering
that much of the traffic on the Internet is video, and much of that is
other content than, e.g., HTTP headers. Moran et al. argued in their 2022 paper <xref target="CBORGreener"/> <xref target="RFC9547"/> that that for a weather data example from <xref target="RFC8428"/> <xref target="RFC9193"/> there are significant savings. However, this needs more research in terms of the overall impact across different examples and the general make up of Internet traffic.</t>
            </li>
            <li>
              <t>At what layer is the compactness achieved? Are link, IP, or
transport layer mechanisms that can compact some of the verbose
messaging useful, or should each protocol have optimal
compacting?</t>
            </li>
            <li>
              <t>Tradeoffs related to compressing (particularly if AI-based
computationally expensive methods are used).</t>
            </li>
          </ul>
        </section>
        <section anchor="recommendation-5">
          <name>Recommendation</name>
          <t>More research is needed to quantify the likely sources of measurable
impacts.</t>
          <t>Of course, new protocols can generally be designed to work with
compact encoding, unless there is a significant reason not to. But
efforts to modify existing protocols for the sake of encoding
efficiency should be further investigated by the above mentioned quantification results.</t>
        </section>
      </section>
      <section anchor="bydesign">
        <name>Sustainable by Design: Data Governance Perspective</name>
        <t>Incorporating sustainability into the design phase of network
architecture is critical for ensuring long-term environmental and
operational benefits. From a Data Governance point of view,
"Sustainable by Design" involves embedding sustainability principles
and practices into the data management frameworks and processes from
the outset.</t>
        <section anchor="motivation-6">
          <name>Motivation</name>
          <t>Data governance plays a pivotal role in shaping how data is collected,
stored, processed, and used. By integrating sustainability into these
processes, organizations can ensure that their data practices
contribute to environmental goals, such as reducing carbon footprints,
optimizing resource usage, and minimizing waste.</t>
        </section>
        <section anchor="analysis-6">
          <name>Analysis</name>
          <t>Key elements of Sustainable by Design in data governance include:</t>
          <ul spacing="normal">
            <li>
              <t>Data Minimization: Collecting only the data that is necessary and
useful, reducing storage and processing requirements, which in turn
lowers energy consumption.</t>
            </li>
            <li>
              <t>Efficient Data Storage Solutions: Implementing energy-efficient data
storage technologies and practices that prioritize reduced power
usage and cooling needs.</t>
            </li>
            <li>
              <t>Lifecycle Management: Ensuring that data is managed throughout its
lifecycle in a way that minimizes environmental impact, including
secure and sustainable data disposal practices.</t>
            </li>
            <li>
              <t>Transparency and Accountability: Establishing clear data governance
policies that promote transparency in data usage and accountability
for sustainability objectives.</t>
            </li>
          </ul>
        </section>
        <section anchor="recommendation-6">
          <name>Recommendation</name>
          <t>Organizations should adopt data governance frameworks that incorporate
sustainability as a core principle. This includes setting clear
sustainability goals, measuring progress towards these goals, and
continuously improving data management practices to enhance
sustainability. By doing so, organizations can ensure that their data
operations are not only effective but also environmentally
responsible.</t>
        </section>
      </section>
    </section>
    <section anchor="recommendations-for-further-work-and-research">
      <name>Recommendations for Further Work and Research</name>
      <t>Dynamic scaling, i.e., the ability to respond to demand variations and
resiliency requirements while optimizing energy consumption clearly
has significant potential for savings. Past and ongoing work in
various systems and protocols has looked at this, of course, but we
believe work also remains. Any large scale system likely benefits from
further analysis, unless already ongoing. Guidance in {dynscale}
simple, and further work in detailing this guidance would also be useful.</t>
      <t>Transport-related optimizations (see {transport}) that enable devices to consume less
power by sleeping more appear to have potential for significant
savings, but confirming this requires further research. Such research
could be performed in the context of the recently chartered SUSTAIN
research group.</t>
      <t>More research is needed to quantify the likely sources of measurable
impacts when it comes to efficient protocol message encoding discussed
in {encoding}. Again, this is work that the research group could take
on.</t>
      <t>TBD</t>
      <t>...</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>It is possible that the introduction of features and architectural properties to facilitate environmentally sustainable Internet technology introduces new attack vectors or other security ramifications.</t>
      <t>For example, the introduction of measurements and metrics for the purpose of saving energy could be misused for the opposite effect when compromised.  For example, measurements might be tampered with in order to cause an operator to waste energy.  Energy measurements, when abused, might also result in compromised security, for example by allowing to infer usage profiles.  They could also be abused to implement a covert communications channel in which information is leaked via tampered measurement values that are being reported.</t>
      <t>Networking features and technology choices may have security implications regardless of why they are introduced, including for reasons of environmental sustainability.  The possibility of this needs to be taken into consideration, understood, and communicated to allow for their mitigation.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="RFC6817">
        <front>
          <title>Low Extra Delay Background Transport (LEDBAT)</title>
          <author fullname="S. Shalunov" initials="S." surname="Shalunov"/>
          <author fullname="G. Hazel" initials="G." surname="Hazel"/>
          <author fullname="J. Iyengar" initials="J." surname="Iyengar"/>
          <author fullname="M. Kuehlewind" initials="M." surname="Kuehlewind"/>
          <date month="December" year="2012"/>
          <abstract>
            <t>Low Extra Delay Background Transport (LEDBAT) is an experimental delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on that path. LEDBAT uses changes in one-way delay measurements to limit congestion that the flow itself induces in the network. LEDBAT is designed for use by background bulk-transfer applications to be no more aggressive than standard TCP congestion control (as specified in RFC 5681) and to yield in the presence of competing flows, thus limiting interference with the network performance of competing flows. This document defines an Experimental Protocol for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="6817"/>
        <seriesInfo name="DOI" value="10.17487/RFC6817"/>
      </reference>
      <reference anchor="RFC8428">
        <front>
          <title>Sensor Measurement Lists (SenML)</title>
          <author fullname="C. Jennings" initials="C." surname="Jennings"/>
          <author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
          <author fullname="J. Arkko" initials="J." surname="Arkko"/>
          <author fullname="A. Keranen" initials="A." surname="Keranen"/>
          <author fullname="C. Bormann" initials="C." surname="Bormann"/>
          <date month="August" year="2018"/>
          <abstract>
            <t>This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8428"/>
        <seriesInfo name="DOI" value="10.17487/RFC8428"/>
      </reference>
      <reference anchor="RFC9193">
        <front>
          <title>Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format</title>
          <author fullname="A. Keränen" initials="A." surname="Keränen"/>
          <author fullname="C. Bormann" initials="C." surname="Bormann"/>
          <date month="June" year="2022"/>
          <abstract>
            <t>The Sensor Measurement Lists (SenML) media types support multiple types of values, from numbers to text strings and arbitrary binary Data Values. In order to facilitate processing of binary Data Values, this document specifies a pair of new SenML fields for indicating the content format of those binary Data Values, i.e., their Internet media type, including parameters as well as any content codings applied.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9193"/>
        <seriesInfo name="DOI" value="10.17487/RFC9193"/>
      </reference>
      <reference anchor="RFC9547">
        <front>
          <title>Report from the IAB Workshop on Environmental Impact of Internet Applications and Systems, 2022</title>
          <author fullname="J. Arkko" initials="J." surname="Arkko"/>
          <author fullname="C. S. Perkins" initials="C. S." surname="Perkins"/>
          <author fullname="S. Krishnan" initials="S." surname="Krishnan"/>
          <date month="February" year="2024"/>
          <abstract>
            <t>Internet communications and applications have both environmental costs and benefits. The IAB ran an online workshop in December 2022 to explore and understand these impacts.</t>
            <t>The role of the workshop was to discuss the impacts and the evolving industry needs, and to identify areas for improvements and future work. A key goal of the workshop was to call further attention to the topic and bring together a diverse stakeholder community to discuss these issues.</t>
            <t>Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9547"/>
        <seriesInfo name="DOI" value="10.17487/RFC9547"/>
      </reference>
      <reference anchor="RFC9657">
        <front>
          <title>Time-Variant Routing (TVR) Use Cases</title>
          <author fullname="E. Birrane, III" initials="E." surname="Birrane, III"/>
          <author fullname="N. Kuhn" initials="N." surname="Kuhn"/>
          <author fullname="Y. Qu" initials="Y." surname="Qu"/>
          <author fullname="R. Taylor" initials="R." surname="Taylor"/>
          <author fullname="L. Zhang" initials="L." surname="Zhang"/>
          <date month="October" year="2024"/>
          <abstract>
            <t>This document introduces use cases where Time-Variant Routing (TVR) computations (i.e., routing computations that take into consideration time-based or scheduled changes to a network) could improve routing protocol convergence and/or network performance.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9657"/>
        <seriesInfo name="DOI" value="10.17487/RFC9657"/>
      </reference>
      <reference anchor="I-D.ietf-tvr-requirements">
        <front>
          <title>TVR (Time-Variant Routing) Requirements</title>
          <author fullname="Daniel King" initials="D." surname="King">
            <organization>Lancaster University</organization>
          </author>
          <author fullname="Luis M. Contreras" initials="L. M." surname="Contreras">
            <organization>Telefonica</organization>
          </author>
          <author fullname="Brian Sipos" initials="B." surname="Sipos">
            <organization>JHU/APL</organization>
          </author>
          <author fullname="Li Zhang" initials="L." surname="Zhang">
            <organization>Huawei</organization>
          </author>
          <date day="3" month="March" year="2025"/>
          <abstract>
            <t>   Time-Variant Routing (TVR) refers to calculating a path or subpath
   through a network where the time of message transmission (or receipt)
   is part of the overall route computation.  This means that, all
   things being equal, a TVR computation might produce different results
   depending on the time that the computation is performed without other
   detectable changes to the network topology or other cost functions
   associated with the route.

   This document introduces requirements where TVR computations could
   improve message exchange in a network.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-tvr-requirements-05"/>
      </reference>
      <reference anchor="I-D.ietf-tvr-schedule-yang">
        <front>
          <title>YANG Data Model for Scheduled Attributes</title>
          <author fullname="Yingzhen Qu" initials="Y." surname="Qu">
            <organization>Futurewei Technologies</organization>
          </author>
          <author fullname="Acee Lindem" initials="A." surname="Lindem">
            <organization>LabN Consulting, L.L.C.</organization>
          </author>
          <author fullname="Eric Kinzie" initials="E." surname="Kinzie">
            <organization>LabN Consulting, L.L.C.</organization>
          </author>
          <author fullname="Don Fedyk" initials="D." surname="Fedyk">
            <organization>LabN Consulting, L.L.C.</organization>
          </author>
          <author fullname="Marc Blanchet" initials="M." surname="Blanchet">
            <organization>Viagenie</organization>
          </author>
          <date day="20" month="October" year="2024"/>
          <abstract>
            <t>   The YANG model in this document includes three modules, and can be
   used to manage network resources and topologies with scheduled
   attributes, such as predictable link loss and link connectivity as a
   function of time.  The intent is to have this information be utilized
   by Time-Variant Routing systems.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-tvr-schedule-yang-03"/>
      </reference>
      <reference anchor="I-D.ietf-tvr-alto-exposure">
        <front>
          <title>Using ALTO for exposing Time-Variant Routing information</title>
          <author fullname="Luis M. Contreras" initials="L. M." surname="Contreras">
            <organization>Telefonica</organization>
          </author>
          <date day="23" month="December" year="2024"/>
          <abstract>
            <t>   Network operations can require time-based, scheduled changes in
   nodes, links, adjacencies, etc.  All those changes can alter the
   connectivity in the network in a predictable manner, which is known
   as Time-Variant Routing (TVR).  Existing IETF solutions like ALTO can
   assist, as an off-path mechanism, on the exposure of such predicted
   changes to both internal and external applications then anticipating
   the occurrence of routing changes.  This document describes how ALTO
   helps in that purpose.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-tvr-alto-exposure-00"/>
      </reference>
      <reference anchor="I-D.pignataro-enviro-sustainability-architecture">
        <front>
          <title>Architectural Considerations for Environmental Sustainability</title>
          <author fullname="Carlos Pignataro" initials="C." surname="Pignataro">
            <organization>Blue Fern Consulting</organization>
          </author>
          <author fullname="Ali Rezaki" initials="A." surname="Rezaki">
            <organization>Nokia</organization>
          </author>
          <author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
            <organization>Cisco Systems, Inc.</organization>
          </author>
          <author fullname="Jari Arkko" initials="J." surname="Arkko">
            <organization>Ericsson</organization>
          </author>
          <author fullname="Alexander Clemm" initials="A." surname="Clemm">
            <organization>Sympotech</organization>
          </author>
          <author fullname="Hesham ElBakoury" initials="H." surname="ElBakoury">
            <organization>Independent Consultant</organization>
          </author>
          <date day="27" month="December" year="2024"/>
          <abstract>
            <t>   This document describes several of the design tradeoffs for trying to
   optimize for sustainability along with the other common networking
   metrics such as performance and availability.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-pignataro-enviro-sustainability-architecture-01"/>
      </reference>
      <reference anchor="I-D.cparsk-eimpact-sustainability-considerations">
        <front>
          <title>Sustainability Considerations for Internetworking</title>
          <author fullname="Carlos Pignataro" initials="C." surname="Pignataro">
            <organization>North Carolina State University</organization>
          </author>
          <author fullname="Ali Rezaki" initials="A." surname="Rezaki">
            <organization>Nokia</organization>
          </author>
          <author fullname="Suresh Krishnan" initials="S." surname="Krishnan">
            <organization>Cisco Systems, Inc.</organization>
          </author>
          <author fullname="Hesham ElBakoury" initials="H." surname="ElBakoury">
            <organization>Independent Consultant</organization>
          </author>
          <author fullname="Alexander Clemm" initials="A." surname="Clemm">
            <organization>Futurewei</organization>
          </author>
          <date day="24" month="January" year="2024"/>
          <abstract>
            <t>   This document defines a set of sustainability-related terms to be
   used while describing and evaluating environmental impacts of
   Internet technologies.  It also describes several of the design
   tradeoffs for trying to optimize for sustainability along with the
   other common networking metrics such as performance and availability.

   Embedding sustainability considerations at the design of new
   protocols and extensions is more effective than attempting to do so
   after-the-fact.  Consequently, this document also gives network,
   protocol, and application designers and implementors sustainability-
   related advice and guideance.  This document recommends to authors
   and reviewers the inclusion of a Sustainability Considerations
   section in IETF Internet-Drafts and RFCs.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-cparsk-eimpact-sustainability-considerations-07"/>
      </reference>
      <reference anchor="NotTradeOff">
        <front>
          <title>Not a Trade-Off: On the Wi-Fi Energy Efficiency of Effective Internet Congestion Control</title>
          <author initials="M." surname="Welzl">
            <organization/>
          </author>
          <date year="2022"/>
        </front>
        <seriesInfo name="17th Wireless On-Demand Network Systems and Services Conference (WONS), Oppdal, Norway, pp. 1-4, doi: 10.23919/WONS54113.2022.9764413" value=""/>
      </reference>
      <reference anchor="CBORGreener">
        <front>
          <title>CBOR is Greener than JSON</title>
          <author initials="B." surname="Moran">
            <organization/>
          </author>
          <author initials="H." surname="Birkholz">
            <organization/>
          </author>
          <author initials="C." surname="Bormann">
            <organization/>
          </author>
          <date year="2022" month="October"/>
        </front>
        <seriesInfo name="Position paper in the 2022 IAB Workshop Environmental Impact of Internet Applications and Systems" value=""/>
      </reference>
      <reference anchor="Sammy">
        <front>
          <title>Sammy: smoothing video traffic to be a friendly internet neighbor</title>
          <author initials="" surname="Bruce Spang">
            <organization/>
          </author>
          <author initials="" surname="Shravya Kunamalla">
            <organization/>
          </author>
          <author initials="" surname="Renata Teixeira">
            <organization/>
          </author>
          <author initials="" surname="Te-Yuan Huang">
            <organization/>
          </author>
          <author initials="" surname="Grenville Armitage">
            <organization/>
          </author>
          <author initials="" surname="Ramesh Johari">
            <organization/>
          </author>
          <author initials="" surname="Nick McKeown">
            <organization/>
          </author>
          <date year="2023"/>
        </front>
        <seriesInfo name="In Proceedings of the ACM SIGCOMM 2023 Conference (ACM SIGCOMM '23). Association for Computing Machinery, New York, NY, USA, 754–768. https://doi.org/10.1145/3603269.3604839" value=""/>
      </reference>
      <reference anchor="Unifying">
        <front>
          <title>Unifying Top-Down and Bottom-Up Approaches to Evaluate Network Energy Consumption</title>
          <author initials="K." surname="Ishii">
            <organization/>
          </author>
          <author initials="J." surname="Kurumida">
            <organization/>
          </author>
          <author initials="" surname="K.-i Sato">
            <organization/>
          </author>
          <author initials="T." surname="Kudoh">
            <organization/>
          </author>
          <author initials="S." surname="Namiki">
            <organization/>
          </author>
          <date year="2015" month="November"/>
        </front>
        <seriesInfo name="In Journal of Lightwave Technology, vol. 33, no. 21, pp. 4395-4405, doi: 10.1109/JLT.2015.2469145" value=""/>
      </reference>
      <reference anchor="Modeling">
        <front>
          <title>Modeling Data-Plane Power Consumption of Future Internet Architectures</title>
          <author initials="C." surname="Chen">
            <organization/>
          </author>
          <author initials="D." surname="Barrera">
            <organization/>
          </author>
          <author initials="A." surname="Perrig">
            <organization/>
          </author>
          <date year="2016"/>
        </front>
        <seriesInfo name="IEEE 2nd International Conference on Collaboration and Internet Computing (CIC), Pittsburgh, PA, USA, pp. 149-158, doi: 10.1109/CIC.2016.031" value=""/>
      </reference>
      <reference anchor="Segment">
        <front>
          <title>Exploiting Segment Routing and SDN Features for Green Traffic Engineering</title>
          <author initials="C." surname="Lung">
            <organization/>
          </author>
          <author initials="H." surname="ElBakoury">
            <organization/>
          </author>
          <date year="2022"/>
        </front>
        <seriesInfo name="IEEE 8th International Conference on Network Softwarization (NetSoft), Milan, Italy, pp. 49-54, doi: 10.1109/NetSoft54395.2022.9844091" value=""/>
      </reference>
      <reference anchor="Experiment">
        <front>
          <title>Green Network Traffic Engineering Using Segment Routing: An Experiment Report</title>
          <author initials="J." surname="Groningen">
            <organization/>
          </author>
          <author initials="C." surname="Lung">
            <organization/>
          </author>
          <date year="2024"/>
        </front>
        <seriesInfo name="2024 20th International Conference on Network and Service Management (CNSM)" value=""/>
      </reference>
      <reference anchor="LoadShifting">
        <front>
          <title>Reducing energy costs in Internet-scale distributed systems using load shifting</title>
          <author initials="V." surname="Mathew">
            <organization/>
          </author>
          <author initials="R. K." surname="Sitaraman">
            <organization/>
          </author>
          <author initials="P." surname="Shenoy">
            <organization/>
          </author>
          <date year="2014"/>
        </front>
        <seriesInfo name="Sixth International Conference on Communication Systems and Networks (COMSNETS), Bangalore, India, pp. 1-8, doi: 10.1109/COMSNETS.2014.6734894" value=""/>
      </reference>
      <reference anchor="LinkAggregation">
        <front>
          <title>IEEE Standard for Local and Metropolitan Area Networks--Link Aggregation</title>
          <author>
            <organization/>
          </author>
          <date year="2020" month="May"/>
        </front>
        <seriesInfo name="IEEE STD 802.1AX-2020 (Revision of IEEE STD 802.1AX-2014): 1–333. doi:10.1109/IEEESTD.2020.9105034. ISBN 978-1-5044-6428-4" value=""/>
      </reference>
      <reference anchor="Baseline">
        <front>
          <title>A New Proposed Energy Baseline Model for a Data Center as a Tool for Energy Efficiency Evaluation</title>
          <author initials="S." surname="Livieratos">
            <organization/>
          </author>
          <author initials="S." surname="Panetsos">
            <organization/>
          </author>
          <author initials="A." surname="Fotopoulos">
            <organization/>
          </author>
          <author initials="M." surname="Karagiorgas">
            <organization/>
          </author>
          <date year="2019" month="April"/>
        </front>
        <seriesInfo name="International Journal of Power and Energy Research, Vol. 3, No. 1" value=""/>
      </reference>
      <reference anchor="BenchmarkingFramework">
        <front>
          <title>A Power Benchmarking Framework for Network Devices</title>
          <author initials="P." surname="Mahadevan">
            <organization/>
          </author>
          <author initials="P." surname="Sharma">
            <organization/>
          </author>
          <author initials="S." surname="Banerjee">
            <organization/>
          </author>
          <author initials="P." surname="Ranganathan">
            <organization/>
          </author>
          <date year="2009"/>
        </front>
        <seriesInfo name="In L. Fratta et al. (Eds.): NETWORKING 2009, LNCS 5550, pp. 795–808" value=""/>
      </reference>
      <reference anchor="UNSDG">
        <front>
          <title>United Nations Sustainable Development Goals</title>
          <author>
            <organization/>
          </author>
          <date year="2017"/>
        </front>
        <seriesInfo name="https://unstats.un.org/sdgs" value=""/>
      </reference>
    </references>
    <?line 935?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Everyone on the author section has contributed to the document in significant ways. The author list has been ordered in (reverse) alphabethical order.</t>
      <t>Parts of this document extensively leverage ideas and text from
<xref target="I-D.cparsk-eimpact-sustainability-considerations"/> and
<xref target="I-D.pignataro-enviro-sustainability-architecture"/> and associated discussions in the IETF, IRTF, and IAB groups. We acknowledge and appreciate the many contributors whose work has enhanced its
development.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAFBxmcAA71925LbSJLlO74ClmVrrewlqXuVpLG1rpSUUmWVbqtUtaYf
QSJIohIE2ACYKZaszOYf5mnf90/2T+ZL1o9f4gIy1T1jazvWNpUiiYiAh4df
j3tMp9NsqIbaPctPzrrFuhrcYth1RZ2/aJu+Kl1XDBX9lS/bLj9vrquubTau
GYq63ueXu34oqqaY1y6/aAbXNW7IP7nFumnrdrU/yYr5vHPXNPTRX0bzuZNs
UQxu1Xb7Z3nVLNssK9tFU2xoXWVXLIfpddFV7a6fumqzLRbDtKCHp4tkjdN7
97J+N99UfU//HPZbevji/NOrPP8uL+q+pXVUTem2jv5fM5xM8hNXVkPbVUWN
f1ycPaf/0GueXHz89Ooka3abueueZSUt7FmGqVzT7/pn+dDtXEZv9TCjcTtX
PMvPPp6f0T9u2u5q1bW77bP88+v8M/2ralb5a3ySXbk9fV0+y/Jp3rgvQ75y
jS4cH+2aatF2/Ge/LbqrGk+WVT901Xw3uDKvXblyXXbtmh2t5rs814nOpxdM
EHwkr/yha1ddscEHm6KqsZYf3Zdis63dbNHy5yDes3w9DNv+2d270Zd3P7/O
aOhqWO/mRK7fiOi0mKv2rmzCN4h/Qs/VRKl+oOdsZP/8TIacVf/ESP/4F7P1
sKlPsqzYDeu2A0lp8jxf7upaWOZttVgXrs4/u/r3mr9ru1XRVL/z88/yX5vq
2nV9Nezzdpm/7+uWf+SEXhs8feN+rJbVbFe1s4a48WCK801FvHw5uO26aI5M
8b4rmpWLh3V4YtbLEz+2/D1vyJHBr2noxbpta9ryf7j8L3Q2y2Sma5pHH/9x
hc9umefSzYt+qFyTf9xtarc/MtdP55fTy/fx6L09NOv4oR/Xrp/27WyxPjLD
WV3lH93vxVV1ZOx37VVVxEMXdTXr+Nc/NvjulmX/vLu6KvK3RdMcJc9ZUQ9t
RKR4ht/w6GzDj/5Y4IezZXVkihdFV7d9/qFaNcVQdO2RaZ7XO5e/IlHGonJX
D3Rk46kWW3n4mzvwlk5I39b5h6LeuKPTvKj6RcqeW/ntjwt8cxuJiiZ/Q9Ju
XhflMRLVdf4KEj0d+reimdX61H+v3LD8kVhr5hbHDsAlSe1+nf9C6183R4/A
wcp7fuTqmws/66r8F9f9n//duGNjnnfVou/bJuGarppdkWygJ350+v0to/9E
8xeb/Lx+Xly1uy5hjbWr5/LpN3fsza7q87czbPrQ0az9kVV+crVbtiTSE+5e
2BMzJu23JjmrSSiTmuryF7XbbI5McRE0WTxHvStvqtWPCzw1oyeOsgaR+AxS
+Z+kL6T4jMV4vOam7Tb00DVpowwa2/8rzz++evH9k/s/6J9PHj14on8+vf/0
of35+JH94On3j/nPi+lLpsx0uO6mnfv7ruocbI3+4EsSbq7c1W66JyF68C1O
9dR92bbgN/t2ayd56tiKmfZmklQ1yQhWM2aM2DML0sT9lddEoydSnYRn3rXD
p64o3fvl8hkT0Cwr+iIvcv5uii/z900+rF3+uZq+qsisct1qn58vl9WCxOqC
pTr9ixZDBA32EnHcivQrzSbM19YnPAsbKPmDew8e8D+9VsT/TcmaIpOF+DXo
wp4OieuxZ7S0+z8Ma1pHRxzb97Su6Uva9abM37kB5kx+uSeNtelzfHbpuutq
4XpMv3QdLdXldz6/f3d5Osnfb7dlUU+IBt1NsZ/k2+0svz99NMnLtnqW3783
e/CQdv8ufv340f37D2dY7+zpD98/enT/Id7jxfP3H193DlZRSjx8kdOZ0y+J
cCTbfr58/y5++/eLoSVr7RYqGBmez/K3ULzppz/N8udVd7Vu69/TL17QF+Dr
pjmk24eWVAu2Yltsad5KNhTT52RIsvHXr9ttajPnYqthf4MVvN3WJCjEymYq
C8XxdpfFZrNPqSEf5f2mbYc1jMRr4sGWbNIC7JOT4ps74rUlLbUpyUavbJ7G
Vav1vO1GPPPwVp553u1ofy+3hao1+/xy3RXX+yL/ZUfyhPyAIvn2o8MxIwlY
fXFVl373yU3/tqPN+2k3HpP2luhUk0V11m2qoVDLyQ9Kgot0zc/tmkRR8s27
anGVv1384tqbI5t00cAaXjiy85tVD7Jjk85evM0vL16/eP/2LVMgYef4yz89
eHg6y89IHi4q3iD2gl60m+0Oyp6UN8kMYkli93fuJv8b7Tn99bdJ/uvl2ST/
4fGj//i3f//h+yczb2nTWYBQvkvH4f79R4/vPvz+3sMH3z+d0X8fPXn4FFtD
ZstyX4lUC7tun+af2u30Jb0rc8rzdhjazfTXLZioa2k1dDaJA86vi3pHG+wP
sUoYtlM2W7xJzAXv2mu3kcNz//Gt7PDLLL/o11VK/p9nxAZkBlZlMfrxtJoR
+w5tygD4edmuU36a5e+KTaUW4nj/fiaF3NDJob17Qww83BQkEoOPOcmv23qW
P3w4yZt2lj+4L5Ln0cOnj6ePHt17HOTP/fv3nt79+c2nGd5y9uDR909pB0CG
t23p6gOK26f5S2Ln6YearIv8Q3sDjRyoiFW92kFlHPdq+/Sw3f/+dtFEsubF
2o0k00sSQEUHmyH9/GyWf3BdV62OkOz8/Dx/QMwhC2K2FW/eWJzVBx1bkgXC
1IX/NSsZ4+47Ly5ekGD/UA1DP991qzX9faa8zdL90dPp/cdPRhSmh0Dh72f3
Ht5nEeZWkH0pcc+/bOu24ln0+/xjK7OyBHz5jgzrginIR45FP/Qny7jzZkWn
jl66Wf1jBRjoOyU5/2ZngicS/qk1eEjNJ6Qhv0VNryrbJbFnp7ZUfoc+x0dE
w7cV8c8kvyAVoKqRaPf40Yh0+vvHYF5Vj0+Ih58yHYlktLBDUgppbAlHSJT/
2h+hM/FQE41JYnvbdsOInI9uJ+fPs+lfZwhtNDTYmG1HtE4oimFp7H+SpJHV
AX+P9AKv9s6Ld5dvT7HaN21RXq6r5XBwgD+ShbjAmzsRfou2H3roaWN1siIL
UjhxkKVXY2fHJKtp7LzXwUcn+RukIbq8LUjP3KQff5xBhF6ScutIbY4o9oG+
odPfHmHBy+rLPyAWHdkN4kfCdrHBpmTsiWDv316+O/8ES+05Kd+ibjs3gRNR
FWarHZxkfQTH+dHs+x8ePnry9BHTvGquzlarzq3EaUjIzifmcqDZi67kw/um
JTrzct46Mlq3LVnPZAScda7wC5xOMWgejRrT+22xBzveu+V8Xn56mT+592B2
/+xfp/hZfueju656lc9HfnL/0Sm9Jinnhw8fzvil7Z3xY/otTt+92dP79x7f
e/iI9N7l83f50x+eTO9PH9979Gj6PXk0UybF86KHlnApDc7YHPiAd+2Jq1T7
2m9F4TBpCtYu+QuH3c2LHk5C29YabB17BarWR8Q523ZVDZZ8ejtLkop9U11X
8FXa/uCrD6Tbhn78BemYV+1Ar7Crx1+RN/ELcfGqgu/YH1PbMbNGGlwUKFhB
3+6j6x08r0n+V1bj8B+IF5m09M7rTcEx1Fd0ZBwYZUxnGTD+ae5/y1Q0QfLS
seeSnuJ73yDZB5ziNTls10fPakFuwQEh6WS57jfnDn7/EUeOCGKhwrGR82aG
ZQ/ECqSBCyLEnfOynxGT0vn7/P7jLxfvXvNyJ/mbdy8u88ePH9+TU/vD08fE
xk/uPWHT8d3ly9cHdiPk2jt1L+IwPFHE1e2W5enrtqjHtsoPhys1M3bX0DBD
P9s1bM325YoezqbTaV7MSZgiGp19WpPLVraLHU9AQnax63tS52SnDu2iFYHQ
mJiPbCY6Blv6q4efN2QbOvprmHwkMSp1nsTVSr1xcJeNNnjrcJZ/WrtsSavo
4UHCW+tacpjAJ6tdxRaek5nyBc1ArtPa1dvlTo6grTUriQQr2tv++Kr7SX6z
JnlMa1qs44F1zBW58c1MKESmclm7LPsOIr1rSUdxCiBL/cTRy1W9vj/p6ILI
mYQeoNN0SfRecFlJX9DyM6Qr2ALg9ws/iQjEK3TCEPBy3FCJC9FuMbqjsTP+
RZr46SM+klgqE4bnwd40pnfoHxuSetc0aEH0+cY4s/8PLOO+ReNbGAhRUiSx
6Ce0yy6/IS+V7APHA5KY24zHIeJ1bok4RfvNCRGRobclt2VwQrnRQKwOeAYi
yw14ao+Jy2SGslqyJTBgHD7j9B7pQBPdG9oqMoHoHep6etXAh6yLbkXDlG5Z
NZX5M6NVKAv3sDKXXbvhgf4zYiW/8+s7suhfn+Zfv7KE+uMP2uvLEYPLPmGh
TvN3vUwXse2i3bjeFkFmLzFGRVIfa+TUIbHuM9r5rrwBrxFf7pYF+IOeJdOm
6ohFzBjc9WRK8nQ4SkMnp5ATeLMcQoNo0w82MB9AspuZPAs6GhJJiLl17hYF
uCJa7po2sK42TKmNKxo+V/qiB7Nm1UDnZKmTJ2uPOFOGlRec5HM96Pmy+kJz
4G1uLJBnJ3DCsiOH+KrIkIDw6EkfL/gVPKmFRYhA+0WtM168+JQjBCs7SYP0
AzhfX4jW+fIIQdOVGtuFCeUQ8gN8QufgKnzod7Ilm7bDgsggxwnAlzReTSRs
r1k00buXfb7SYKCOtvWSdMKPEBU4Gk3LWckflY+88SJSJkvpTXvJnLYhGxkj
b0iWNwMx7Wcy0fNV25a5KAR+w0QQLUTmkJJxx5VUFjaGvicJuCb7irjQdfgd
nXBE7xARlHMu82BRDVmUJgj7DBPPd1Vdylcy5AwqZVfhddnN/Idic7FuOZyL
VR9KzLG4ys9EuF872qja4XwwqRGVuY0gGYbeFFdE/yEna7ivICPoxWQ6fFRF
2yPbTnu0IJYRGZulgr5uyYAmbiRpR3vf7lZrPTIyOJYKDdayVCQa7Q/HIL+4
1DgpuSB19bv8rkIOnCV1CMVuYcvQqYEFsK3bPWcjoKla1umglybPsWj6V5FA
KEQtiXDfkphvhorVHiRDkY11vFKAtbFobdqhtq7dwkSzT7MguuBmq9kk886t
j0md2rlr1I3l6eNH6d15S3o6cqRf6N0WlRwGtpEcURRar4KVR8dxku+QicI/
mN22bHMvkihYVtF3ZFjt6K0bcm+86cMuC/a8ara0tTT1UuJlW5IJRAeGOdj8
WQtlFPSHW9Kih14UXoloNMuK8fy03r85ohy5IiXcqYhoeKElET7v4JGTuCh6
UeN67sBGdFY70sMViMQWXFbkN8Ve6TaA1UteQ7EgYb+rC9sO8nCvcp7xTjUj
qvGf8lRvi1C53A8kS0ph74besGNNfopDRUJ1vGp5N7F86Hz2nuoTEx9ED5Gq
vR8e8rcnFnKm7yvZBGQmyAGj/y6I3dVw8fIv8zpdRybufs+kSllZ2RwBlEW9
K6GiWMaPjjWHVLKwONpQ+weZEPZ++lp4QdeBL4lKtMzxkZgWrMiXRb/mXcYx
h45l+RCHPKA9WIx4C/ALffA7/XrQs0WDixWOuWmtGz0/ekQ2yN4vSKKdYsWD
nyfzlmBlbkLEiAIQwhM9JqNl0Z5BD/YsY5yEP4pMJh6K/spmndM7khAlt7Xl
I4WjRlzG2sl9GegUnbK93JMeogPTYUMy2wLskEnIifxEtFofDOFgA9Ofv+Ew
m1jPxsaheC4tppDn2qYOD1cNPew4FymCFkKY5DrwVEg6lY5ELSkz9nxIrMEt
mcrv2RRNuUgVDgk5Fl7lvik21YK5Rs2OIu/I0CKqGqPHclNeAr/8rRroR0Br
ZSRW+KMF2bV0OMlaB5P3JsbBlLVzW1FNyKgWg0rXDRa8KGhM8Ai2DHZFe8NU
qNQ7AxXI9OZP6IthsTbZLA+oQcFHeFm3N6we8IFZhlXPObimFK0D/5I2PoRn
TchpBhGAtUkmbqpTN0ziKPArIY/tl/Jd29lhYEu/Z/ueLaeWaEczyx9KRJxG
DrioPSxSX2f++OmVLj4yctM3KUoOxbYhiqp6Uh3lWNEGprjBwUl0MFZNhPf6
OrZu1Ntm4bG0LIDKa7DlRMYj8cMHJiaRMk2yDP8saSPR4hDEWPWatpr4Kpwe
1Vnq7ZcZGwlk5hRl2cGoHrtGaqzOmGYSZThwDCrZCd3PgknOCtEsJqGo/Ebs
NR9tgMiLx8IZdcQtdPxkRY71tdkZuo8Jof++E8SAvHHZOjGdFnVRbfB+C2g/
8WXbLR1F92VNfoyYkAcuORgA5x4j8OsSSxMrCJKxpq/7HTv67Q5+3Dd8X7Jb
vizcFm/U9ur9bsUEZkU7YpXYe/FcYqxBq7wwMtPmwZ0uk4jHQRSiQFQLVJ/A
wW7beiKCmliBjcVxQr432IOGEYz1ZyG+TqzQYAsgBuj0uhYmYfysaC+vg5OQ
jfxQVQhW4M8WiN+x9hBDtlfnIF6daCvSOjMRz+APHuV2RxpEGNTDYI45NiZe
JWMfRc2RfyHvkhxOdi+TJ2C14b0T4pDXZgeWH8m8Y44JeJDYdRT6rDhgcHCG
8BR4bmizSv3meAUxoc1+hDIDe69bMBgExmhfO/Yrh/XNGjhOegVIgw0EFmBa
5vPC74u0HvmJe/DKTvMrWzKgIb5umI2V3sqLLOhlz5I1Zd7REAczjqUZt3jR
KTSVHJ+mF132CuerCM6ufP3ZzfP4G/5UterlQGy34TgIrQwwMDJLlu5mhjjk
B68cUgD4mdgSKgR6b7s5UKUfuzqRFvCiLYrK3eJjfjOQy9FMeCKuIGKwfGLb
3QvThm3368rdTDS+JepdgRo36z3s0xuT/iF+yoJPQqj8y4ONCCuYsFtHymXf
V72FSUjhOiW0JKjVqYnOGC1y6ZgfiKVB5+/yt3T0dwJpM5kFGS60pyUFN0t8
v13HgT2YMuJfLpdFRTw0lzMOXtRYA/ulpr42ZJTNcvZILmEc1uC+XsxTvwA5
ASSzYLF2zNSYqBPbqPVBjHEQgHmh6jPm/AXsrXovqy34nBEj1m0rUkbiA5ZT
5XAmHRT2BTNyGoapkRUYGx/vJc1Bg1aw7lgK8PIPVk9LIPWDQL04lrIJnXgu
YtcE+wMOJtvZbDhg6Wa3eX8qCgoMiIoOar3bmBGhaTOf04zJcmAxsmqcs+tg
CQQ2zr2VWw2SveszsbnZpZv2xXXiBIsyCs63wDxxWBC0VeMz8wGuY954FBVm
i5dtrNgcc3C2ZHoy3/3cNOt1y2oy9fiTiJqsl4jKwbKMt3i9G0oElAEnaMv8
mnY09tR7iZzar8RjpV3YbcUVLKHHJ5m6Xt6ftD3BgWuW1WpnfoqGGNTesS0s
dy5ThWZT8bmjg+flQpa9HZ+BIjoFG3L3iqbqN7wHHF9NGBVLz2KPxG+y2cq6
1yGkMhRXor71HMzyz6RFycfJEgbi8NGejdoJhyJ6FlfBsy5g7dGHyyTBkrGD
vGuY4yVG3sGuJ+MtvzgyCljIxpAF4SQ5zTEPWCcJNzoh6tsXqwKcSESaW/Z6
g+y1jQ6ez9IpFmu3uFKZv0aNA/2q2qhAaIlFyTPHv0A2QTBCp6Ewh3bbwkW0
cWkIStQ0RxC6iv011QKdyD2JMUZBrmKOgD1zYKbR/uuiqjG4ChYOdtEelmxC
i7AqFICgUjNsFnH2tHRiYcDVi4YXA2Yi1nnQNhb6J8JVrCSySAz5489EXMDj
r72hVfrEhCPzvRnqvbg8WSLtOceBoyXyhiim8dke6p3I7IyRYDrFO6SMlyEO
tectIDUrcm7DsBBwYsSdZBb1gwbzKuSHy1n+kbbiGluTjSWz/VhkAYKn9V65
F46XBEDYklRO63FM5sTQsGKSofArDt346LWqxrBNEoPpQ2rqGIuAm0iH1SDk
SGyX3p1eVg5ZBl19Gr5TjLyIIxqnvclQ64TgFs1FhKhV0pypoECuAAzL+8EG
X886anMkPzdl0SpJokQ0ZRGTKXv9ibi9dqx0u7YVMSUiMX0Ya+agUXIkJDhA
Shx6akXvDQJPjqgQhMM5H8WKDfwzVyOahho4UNTKCx3mGvsjOR+ZAWPNie3+
vrNojppj2AGntCkd/qwa0ztyOOiMd3M269phS8IJSvgSaqHEnrIJB6Ylt1ac
YowjPptEO+euRPxFRzHDtIVo4EV2BaI+NHMFB0QWOk6bjVPy5OySheU0Fnap
9vGD2QPxm7vSKNv6NFW6SZzLwDGWI7SSqLCK50zyiUrAeHP0ROtYZdjWM6IA
z3hXpos1jAVB2gWZlTz1qucA0yHzxGgIyzfbrvj0nfOwpFn+EwPRCux5k3Bx
mnfBMfBh1AJBWxDmS0VaqFlYAuVg+Gzp8Tw4OdC1UJJqhLEpUw2aGuaM+zgf
wixpUYFIdCRHw+cJhv3WRFZQFzhO1fAnlaSR5ctObSRS4wTnyCSLEyRmsAiL
Zq7CJsxyctOqujZForaJxpiX7FR17JzsejG3e1Uk4JZkq83Q1BBlMOdFSpkn
giMmAKoAMtMkp8hrO4OHAuLOJUcIH5zqtl18msZ1RBMffEDShNgCx1xUlgaL
iMDmJwgQbgNJujCzHACaa87gwSJgZYISWbYjhb7Qdxz5ZB3OfAp7gqxPcb8h
ZQbZkPFgrHzY+PfEnZO4Y29fMhYLRw+UXAysFmWacPBBYyiQzHOKsKMJ6kIM
WLbmJYqAAtlBdL4Xfpy2Et5L5/DRK/aa43IoK/KwnAu5B5nPPNy+BNO9+BcN
RE4OQIXJpD1Q9EOmOB6Oadi4zI71TbGHrmb7TVwhsNPHxCPOsvfNqmU7h3X2
4OPatKLXH8/P3+XmJHMNs9iRnSvKffC9kERjnoWPwUIigfIGThS+EZXnRUXP
ibYke5JWa4nDtt2ynUznsysFTrNxzhBMODnBJyVVfC02HtEPBoAYrnEIRKMe
UE+LChqfjfOtokDt6L0W/kdZavbZhWCCisWR5RUJv7GqNbMhkWP9Wkz34MhE
8WxmljUWFfxDlIz3ksCNDIVGMqNmwsLoySENAPeSc2q+5GEyNrukp1g6CrlW
XdFAWmpsZ5zr9CKKjS5x8xSOFvBktsnBKlP9RCtYklaa0iQV3rAVFK3JeFaO
mourom2uUDZZLfdRYgSF/Gw4pJ4+79kLmZbxy1gGG5vnxpTnhpIhk6RqLDfo
THGy7LFYVxDdtCmLrpo7llc7HMaB6QVPiPa5E5SAZJ1b8rlMmCVpkzscS8Uu
CVuzOLbTkkXwndjEXXLKSDaAWYVfyofRPUdqvkqBGvVuNa2aNDTPgpTWtqsj
EGXG7Mpf3cGhFmqpR4OixVNvm6VOLyeWOaTQFWWVZnRi4JM9PqEBW84bqmuN
ZKiGSOmgLK4U1kQmTyFxOCAOQakFc2G/psPehz2WqO9LR0ZkF4KIyAq88Gyn
HADdg3nIpupBVvq6lFeO2dvpu5dciG42MTueu55hWtmNuJcsJYhLSItw0RHZ
AmxUTTSAXHlRDgebqDrwmSgC4sDYqRfb0S8Av6DROO+cf5Y8nIss9Dv96V9y
+SKWO9C1IvOhWf+Sfeg0oGE/rjwSoLzrvsgfyma998r+cirpRL9UcyrgZLHV
rNzFoqfWlzBMBy/5Vxrtb2fvXrMDPcRjoQZ4g3f7Bdnd5CsgqVEhbMobHyI3
S/NnnlCTRMJIeEssQfaw2IYoFuKlto2k3+jHdCozYlqJXOCAt7Lx0K+ehcND
SJmWAjAShyw2k/qcLWFxJSVZCxKS6z6SPGzGRsUREylrZAttkr+s+m2NmtuX
HkjDZE+5gAxX9o2GdQfYFM50tZWQDnNpJJOHNmCCZvnzfYxDuXEMZszRx0KR
OaRTti5kwelpzpOHeGxYuOUJbDQeJUQmwXbQ1Ny4QUK4gq5adhwKWSDKSrps
w9KSzt3gBN3phgV7hNuiU0HZu5F6JsnDMUO2mPR3JruqJvO6QdHQndsBXsG/
KFJYEiMJAH5o0KoFS8kSzWV0jURL+PKDJzoJl4+YhMf75EeDDf5GrRC/Q5pf
rOJQiZqlxmdQ9JYrDOthoiv4iQun2WNZtCVjODmaLy/cR2FWQzjxgYsxSLYc
SRpziIk31HXEAgqY9JYtGQDZEL2W0J5D8P3ANqVnGbCmMeYE7UskNIHAG6k/
xD0BSe9GYWn1jTXUgHcKGNOh6izCadvwUuyzTy1ZmCCHuQGQMR0dmXMGNmpU
NMYMqPUkwXELXbKpAFucLVaIyY50ibcllwxlM7/D7Bcxc1TtsTMiNpIOUpDw
gNjPYqNIQFDyYlXkME9iH4CrvLedsA1r2yzKJiG1KZncyKsXYV11SaZKkp9f
BsGBqBfKoZXoPcVsl8TXsE7DrgLEhbnLuScPGyu6KFBv+Ia7hoPBQecANL0b
/e0hHUQDV2iulVzM+BAmcpRY+T1OCRmZ8N7VrzAonnhX4Fm4nGxxZUcSj+Lz
CvAQhZEDhr1YCuUsBV0I9Lpsmz8NMYmx3fgMISan0WE9PUyP8WTKERNeiLil
lvYW+8nYbwVtjyg1YugV2SylJhOtPvnrdxv98w8R+9tit1Bje7edDu20lEKO
sEn0v2AbcjaGmR5JPXI3Bt4PhxiZJDkO3X88wyC73caO7XZHEhlR+D4D4mTj
UVa3PH4Q6PEwnMwyhsSHMEcQGF/TQphZVuyvkU6VegVW3cW2ovHocO683AoF
LqpwgA6X6s8Xn2SZIih0qfQYEWRxRXPRznGMmzHWGjaH7AL6E0pDFlBzABTG
oZjz2/W+Z9aLrSjYCgY0Jg29EDuAA0ijXwpBcXYL4WDb0yMZrM9R9kDzKRqV
UDi3nNkSwlnXnI9iXRpNUA9lgUDg4KHcMswscFiETjxIerIBN7SxVGHpyFQ5
CIp/arm+jITeTQv3O+pZEPB+HCq2ufk0LYAVYmcuC/VbhaC3e5jzuo1xAcIx
mPAnZq9oXozOpTRKCzJBTubSVGG3PeFdORna7RS5xBMDmqPfR/b1q7Vk+OMP
9DW6dgiMIGEYDy+8J2AFxrjZl8hnLdYkQKol/Dh+UPh/ozhX/qYMD4jTwKv0
bwtT/2j+V5Tm5MDyWrRBDBtQUfqXfP1q203vo2sGSH3ja1UvPnDtuBXBMb/o
v4HCY5W6THshjHB4d15dnJ16W+/yxcX7d1KlfP781zdn/N4cyQNWF+KBNpan
z5hY8HxlHIvHQWEZ3B/LU+RojIEEgdxiV1eIP+gvaRW2cp0TeQTGFElFlBaG
95WBvTMkP0vx4XF6ZB4hzWg/jkg7Tv2FMq0jhRjYCgkddBGFNdWdBoslzqUJ
X4N8ZNdVhywJMlSa3OQgNb3EnfunYTthLZLT6poeifyTFUnONaTNJOMEt0ge
YWazpIjA0MUM5/RQQU3zP7h3/95//Nu/o1Z6ogGOJA5NQxyX/Z0kD4f4sPPW
6HtksAR4u2QPNVRn7tzg6gW5wXW7K2cnYsMKE5/BP1+3JUt+lt+faG/mcmq0
MA3Rai0+DnXYj1/nfw0kzD+eveu5bjyLCu0/7OYecMY15f+6RRF9vuLsWD/o
GmAglKFpxTs6BWh5IND/i7zYsBnByYJqCW8KMojNNxpDViqMRWu6poV4S4xj
AGRLoVa5YNqGBTE00cvM43FkpsfLF8wE3ALCuydkmZDIJvIN0gjBtEyTj5xV
gSCI1SgJgIdxDRnvlEUpaMPJ/MjkxxJ1jCvONCokkEv8YsdFT7A8kBWjn8qh
5zpWMSLJvGD9xJk53n0ybCUEp7g52GuxAS5GngycxSjcxi9ElyYW2LwAckED
/kqViZlxnEkOlnlp7DQCjRSBiJyiiFOIZsZwztl0s8+Oc5eOMVVhqxbXrai8
l+0O9v4LJFTY7fX5H0n6uwiB2HFDD7Y4Mi5vgBtt52qWny1IF5Qaw8AAr396
jaCCAPiEn6X4CZESxhFki263UKgafY8qpX6twZKo5pm9Y5TnbdQtFW/VbzDz
oVFXc3aaOyNzPbw4a/7Bt+bwwBZ2bhjDDDLAubK3g0NqmGm1cPrYTU8Phth3
HNeKKCdkk9CE9LA4WCKYVoGfmQKmSgtkcZahHySENvJVhaHDC84dsrAIl8g3
8WFDenNvuHMzpEfbLynoicAomkprrtCSiliTffHM238qdSv2Fw+ZLLg+vaYf
JYagrCxcQjsJtQctABKMHJpAOOxPFES3AgcTN9oGw3DPce8G8sGNr8TC86Aj
Fn5LgFsNTz64rYW1NULBWQzLGR3xL9jRuQ1rmsU139ESPSLOpStjq5H1gsTt
4HRI6jiBNU901xFV1NPDyTjNP8gMfo3gqMKn0PnLGPHjoy7sgrCaBxkmhhBA
cL1muJNTaNNwGAWUiLQPf0eWhvFHpnFq4UF3y47gOSmemkc7OBmpDOQDAnag
siBGFNVPaoy1HIyLWjkkDH+MyEUbK2B4MoLEseTXgJvOb6bPAY/kIaqa8aAj
6JklJjvWD6klBbQKAEwQVrO0r4jnhCh3Es17AOc7+o4sFMJelTlOmfiyJrmM
m4Efj9jOyyO2UNKJJZQgwCTLqAdwlQfx2d7FeTRFcZKXwGHOuJgmWpl4Ctwk
YOS43vKif+qPIDk0VGgLn+TShYBsvHDgJlHkbdGyiuI8HoJ1aH5dIg+KyMQy
KVjwSbNEakfxmRuJBfk0sCuVw8Bf7EXTnwkbMfDcLA+FTBoFudwVzQE07bWn
E5P3tEZ2+6x3Bn3xOH893zJf5zekzAzHKC+SjV6k363Q3zN/kj7k3a2DlwSX
37+XjaZQ+HNESMGgCgxESw9kdxR8bLwrtNxtV6jr66XFbdXs2l0PWULmAG9y
v5srMDENB0D7dKR6UAm0zCLBq4cqFO8zKe1sgYWeTO/fS1/aao/MCFENbOih
W6Dvf98VOOAQY/uMFwy3LQSr4+iBGC4G3LHAsXVdbVShMN2NajBDDNIaiQ/L
c7hmDdZRgLq3vEcVl5yncJL++vrVmkKR140h6YNjbY+4ZcYxpMU5V5auOaEz
j7RWXFkwEnzfTnkLs9lWb9FKniMJVdQDQsI9Xqyzuc/ny31hy+cmpL8FuhD5
Jh7VwuVo6tMeKVyb5RzlfKl46kutEP36Xblv2D3/I8tejspHVeZHjViK8jek
GqNi6djsLbnTraYwLNDHtdIa4M84mM4IeVHH4vgyzZBO1Mql83FtNBvkjo0C
eCYwc+OC4FB+xjVHYOZyJ7VJcLibKwuXO8nBZ4uiAx6AvJ8popyA90qfP/YA
mPfgNIlvAtssLYFl2cnhb3KjxUGEDbdyygGalWgsjfYu3qMUH6QwoL4NsfYQ
jNAzhL3uSO1Xq4otNW4rJK2Y1MbwxtchKA7LExIwYPra+lNw7N3gR3TyCjLr
B4ck1lnP5hgasE9yvSXCal44WKKoW1Sl08RiCvKJR1ZAiJzWXPgUKWq9G9Tc
0urRYSAbgiduhZXgbl86Fh5glKZsoGVgLMBcZPAzd9ukON5XBhqwRSqVWUNr
hkd+UCrbHgkMv98NgulcjppZJLJyko/LriFmo5oGDuO07AC25CEoRgTIuiWv
WNsqHoZ2DJCUVn5KsRdpEzvDUgm23TqmXaFSYCp1Pnf0PUfWFQeCtLel7i0q
tblcP8DDe+1xeTjUEJXrL4W4zvPZLaXjp0RiuwSF1631WNJt52hHnjFlJWAB
3h2VvlVNFsqBghvPoD223D3eSoONMHtYlLBEEQ0WkKjyqwmfZ0Yt2qEkHa6r
jiOL3lJxX9bVvApAr6Abxm9i/Y0GX+ks/dQglNKN4uQ4W60hbX2ttWN4zdD4
h6UswJbNMHJ01LshI78ZAr6ZASESu5ue+5KVc9ANBad3zs/PT+Vwco+euDNL
tF3KaInthQNWMz8fQRiy/qxFrtH85+dJZ6dQyxj40IAibOiLAWXcSzz1Mcgh
PeyxgeFrHtL9VyIIhlNq6VSKyDnk8Mp+4sMtR7e76EOwRJg/xhJwCIkrqybY
JC5K82Hr0c9vEBIpxfftJTLslYsdJtMyola40Ymig9TdqmoOcQhswKO7ojhd
CGx9AY19lO/SV1wxnfVBJSYuOtgnjozGbDg8pH6rxihxoiSkHPQplwOzTpV3
1mKACmKe4cHkPJVigs/3Wp3HEZ4U4QfhYZQIRg/ezyPM0cBpEO0cRwmVmJhx
pKiRgLP9S0TVLNeu/dIXqq/YfMUzEC/kqqCENBMsNIMgfFmBbZEEiFaa8OhV
cumTrL58eIAftFezsmvvbNgxr3oxBznVoCntri6nN7yxbaaZSyG/3y2fBD9m
rijzz8VIY/5E13cWIyRNHcOpGl449lqh0Ko1xHCSLaCjTvzoX4LTO0pKHohZ
SYuxcg/2koh1vnQ3+dXnNcdNOUQuoTZ8BOfF1xxxeoFsyVv6kpSxN0aqydGJ
7X1TA99L55aKAo4AKZR+kk6R+Sk0JsnzHpFraumDOtNwl0haOcEyWiA7guql
HYZsEGA8f3Ej5GrncpqqRg3A/MWHX7lXTVqlydJ3IvVDnG3zBcK83PggFBtE
Ork8J9hVLNAQz80MhA9co2++6ZH5Kg3AKZK6g59Pljw3vwI6DWaOFhext8JQ
PG3Vw85ivBS2eny3lAPTJ/NWGwdfy4PE99hVWZhrzn0V6WhLDQjXmtfaPPda
2qS03pTr9qKnChY/sKK12kKB/ddVkZ9sXXGFpAbk9wm3iWdolhjm7AtZ0rxg
/VKpSy25axyO6go5CTFeNfIjT+7Kytbh09Jwow7NSfa67JCqmvctoZbLWf4T
UVCyiVUf15j1O9PrE7UkWDmsyCFFkaMHDMWZ8dh23QPh3FuoWryCPrg0UctW
76KOqu7VXJVWj7pZ6vO3jcC84pOjoAJtGRTcv6WiEVotheidZclgIxMj37UW
RltEKSRgsKwhvNiA63ZNox64tMqaIBniiN167V4wQCUGsg6G7W3AIs2KRRG3
agj9P1kqkrk3MP7FMmTeauFhr1EYwg7HIG15uP3A7JCFfYaFePYg18FMqoa6
zmOl9oy7jfEoabs2g6ZwhTF7mjZRdliUbqWR1cZFgWzp9A5lKT3KdP9m+R1U
6339+p+9DuiPPwTOJ8UgBjGy3leC3YFanrbz3/TOnhiXMzvNfz1STu+NwKS0
Z5k4NPyPbUX2UpZz+jQOljNxQhGlbacFMzXIjLXm0XQmLAppKWxd+ULBuvmz
HGNTj7i3UTRKEfXEibsp7kSpsDuDMFdUGI+20IMLbdQUWi4NHIImFMeG4Rvm
XR2IFzllz7Lsz+izH/pxqX9m1WDR0dAuN0HYM3aywsVZitRTI0Fca3XMlWAz
hhZyQ0BGe1vtOESHNInLtZMDl/p0anQys9YccYubyAWsMy182zupQs0lTWlJ
yPgBlHWW3kOUqQVBECQlTlcex704iBWwwXdNxarWhx6UltKRsqERdJMQovyz
XhvBB7koiy2zNS+s+jt3eUKyofclKYY4ZIHC3Rn46pe5b4kgNZUcj4PwHqef
NahxEEujMc5sdr4i4CME652zNx9PLbeWTlCwhFyLg5MLGhwr6XfVsX1WGB0R
RKz9qsnHNxHkhv6RbYoH8Mk9EsxVp2swOFCZB9iQPIZN6roK5eL5m7MXH/I7
B3PpxV4+FX8q3ZkFWceQlNwuMsi/fh3dxECCynrAtKXgx7j528Erchv6GBxW
jWCuXvv/OT8LbOX4moKTpmXFgAN6wsaelBSabJpEKPqR7hc5AXy3djwAEghE
umt2GhkHo0nR99erUTRR7M2OE2mfzrvteHQI624X8HBaXshdR0AVDDOeyC6V
8/q+4u5sHNWIEfSqVQRoPccs3KABblyOTDpfFgURCRXDIst9idMGoRUDznxl
wRlLneeGpSuqmrFhqDEfxydFl/OluEX0PCuNihlVSy6JSfSGPWIOUX1Hr9j7
4w96aPR9csve4ePJNXucofhzHsIyEIbFyjt13oZaMu9weALVpjAwnLSHkUi5
RguKcdfX4AyYb9c5bY1kEnHfLNa4kOZ3FjBdK1gl39iUA9ASIzddGS+yN/xw
DL4P3dfGaugImiACHsoWap+BIPNRYsFVBuxL+h0G5Z6jm3PAEinGiBSJlJXp
7ErGZzkupBKrxNbl1FPSszbxVZySJffZGB6v0Cjm+Cleyu2W3m5oDUTciFPA
OF+zKUzzsKiUrZXogLcjhJk5IZ3/lw2xIjXFomXx8hl9WmhrdavxUP931VVl
fOeBUQ9qDkpCL/uZjRogFyrw6cj0W/RlCZowrqmgESJElhSSwGZvOwl2CTv3
bFonfdMrBM9tZGirLTqYwG1gGWJoOenYzC8h3GzFxePlQQD4BXrgQslIZzOX
WLMLjAK97okIXGPVi4PBNWkYBofN0l5xCW10NOXkmk4ctS+jMVJADKdDpIAl
uZmJtFl0l5PJE4n2Sg2MSjnFSYRGAkW1kUo6U2h4Q69xuSmrJIELyV37LvDH
sLWsIyMshVTt5ZaXY6wBkSYUZIVOIywxNNgqqkwR57kXLsjKM34MrhnCJXGE
nEf/n+3lKBs13/P0m8pXVFjpBbc3VvC/vCDZ7FjoRHqOKIgIF9WgeASP+G5q
2wJixa5Ijpocil9R1LhQYVhvogvYaBi7XyxqYJueFdpGvWmMDiuxft3ue8vL
wIOwLQxXj3HzQG2vpQ47DRK+B75eCpikVFO8GcmayenBAi8/Xn8foiob6YFJ
J/OHe/9NI/v8Tx6ETXbQ8fLDq6nYaEvcWsoG6eQwpBsc5K0AxI7n4nEgYxwk
OgbE7lEEPfHJB+shhkrTLGnYr+JD4rW+P5NpeGTfSXsIQ+AwaG/gTOqG0lZ0
vrRbQztGSYnShsQiAgyNpUMiB1XS85mA+ycaIzswSMI45pOG/j9sb2XIURgm
NcTEfde3qM9zSNyFwk/cnVBop4WqJ4nFkZiQ/MVcq7qdQ2UWjCGTQimprKR5
86/fDfY3SqX85/5aBV8bvazdF+2WhY+ZYAe3GACanEKtRdRYksSagwYcwhD6
0Irb4ztgB6yVwmBR5TducKfAlxCjfBa1HpkT09xUJfo5cbtqLo+3+4InCTCC
E2JbJ3Kcu4eEpichE8JMSEZ2g+TC6ESE5eJ3cfN/LrNGMEwwC+YvIU4sN9iE
lBJ8s37CP94it5j5ZnoSf2U78K+a0EeekVxsEV9+GyO5ah0YswVqb9i169x0
6RDqjaJNhivyYey1BEIE+HN47UWaeEOJd3aj3YpZJYptUQoItIgu2vBtLztn
+WZuSSrJNqBrrStpo7q0tGaNjHmUpuVs4PbHc0kIO7XzyufyYIj4nEHVpRaG
d0XFoecCPM4rQjpONYfI1rR0h/Q7xxtKb8jwxB2QQPwCbaftPZZ8EsWH5xJ/
hVxLUdXhb6SHXhzuuAvW01KZpLDllhUSNQ6gD+Ew+42N+g8X0e0ge4VHaCN5
g25kSCWxseNpbxeCFVYrOyqskB2eWOielqHM4Pe+7UKJVDd2VzGoigox5rSx
puUSovQDYr964wo3bdM7fqyjJIn3OHtu6JXhkCaMe9F+SRx6k25LHsWepGKE
5HFQS9BraWbjLCCBGI9uKCyLj+Z+cJQGqhjxwfMzNMlZ7eTbr1+jC9T/+GPi
sSbZEQcwPnihIi1UV/lTBwgy95rk9C93Ze7xenI8NKeIXKvdjaGSsJNbPNg8
I9NeDcjP1auKzxuu8pSMGOJ0C720RwO4qJcOJageDlBkes8PHQNUSIRuVmMy
67J8hjLhvBHmqYoygVpyLnHSuPNfxlWyXGsSNJgaC9ut9rvQavdOO3Bq5k74
ds1QOa9lpnynASd3k77acuPIst5xHbu6waNm4ZJEQSWsJCgk6Bun21hIaUWZ
TxuMm2IGKJIPQAZ16Bsj9nxJRGRRzHdQQPiLu+f45h2alzk9EjrIYCyLnYuY
adR5XJ5uGAnJ1pO2wFAJGFz/rLcW3HJhu5bpyQ70Do5iC7OwYOtuWVxzutKU
EUym3ZCxITvlmKZu9D65OkSEqlyHQTYznXzGDPID810nXhZfIE/uleXgZCUZ
W4KSNCiQ9j/iPVurYp95YxPX9AL2Khz6/plBApggnOkUmRdfrtPnJ3ZR/YmP
6PXZHV/xNC/U39Jqi1P2bHRkMsaik8w9dlW+QOFMshH+a8Ho3DRWGaKaRX7C
Yv9ElMxffDtVUQrL/KarpOjKNIGvuOYheVc1L9BuJR0jRkuWbNgksXSVoiaL
EiSqdqZB+AYuvS+y9cIT/Ni0zVS6Rx1wnoUAp1FHp6x0ywLGclxXLFkjvorL
PeN/vTl/+fzsU2RAWjYpC8VuHFj8/sn9HyCpfSDcd8uQ3qD0IbdR4VsTBb+Z
nXA5hl6nh9no05N8/HrsZ7AcG8QEkFi+NnyEQNw6QD4knNXsx8Q5C5kNhGcV
wI8LBmSTMg1gGOl5rWb0ROl5mHVYAQPdOi5ex78zS2iJD8eAs03LLOURXJqG
lawrmOy6qP8lOvd8MZBXWXFHBt6ObuBLXWIWjYxC88o6tym0W2oI1dgaxC+T
mUmgx2CASFkrox2xF+4USuCNp3DGYJj+NIRJB2m9rK3KdtwvWEFKoaFEWk+h
5TwhEi4tQcl3wxEto6X4OEToiKE9TzIcdoG0WSs6HQ3XELXS79Y+M2CXR7aL
FsgAIsUlitw9OE7BiQ8lTpBBIFEdKnwkzRWbfTqMLz3EjiQ97fiGKyak83GN
nuHfkMBc/e175sF/sQCzd2E4EarX4lhI4YDuXBXp677Y2a/WYEw6WwroKxbW
+CG0e7DrLtBLcQO7PuO7F/mCp8MuKdbN3Yspvz7ylWUvNN8/SNdvPuRoJel/
GNq7wHSNrJfD/t0jRAbsAh6hk/6E8s8stvxEHpS+gVzizxpavrALF01jQMND
XvhmSOpvaK97M6nl/G0EI+kZck7rR9qjqDNLLET2Got3tVNn+dsQ4JeuxVpS
Qx5I8vbekNH8aDB1/bQ+uHNbMCrK1oZugxKWCiDcqLUBOXVOLPlwMYMH84VW
opnVu4QGCXJQIt5WMAk43zo++fy/yL4Y48nlxrT2KXcXirrDHNb1KRpTSjYx
8LIKjcJZ43389Cq//PXy09nFu3DbFTcEkniQb9eYv4F8Zn/763e1/f3H6L6T
cA1xHEKBTAa60a7fYW+qrpZsKUTxpKa823ZHRHwcSSfHhgz/3+1iPm1VncTG
1fkwXA/LeO2TpcU/1cCk4dZsXqL7hdwNM0dgK0PKChCzjLJibJbjtayaUpLx
UoDZ62GvpbMwc21wvEpuUzTwzWTeL6vM6Pf9wA1nLmcnqZiMyyW1FC3p1bcP
Df8V52WNb2Cy4kf22OiOE5UAjcRDQ3lcdGWU9qr89k3RuMhnK0CfiRE+rU/x
TK0GIrAisqYjL4klMRiuZ/gXOiPDuxdMyXrXrHTpJ3rn7UmM2uj1ttogMSSY
kL6ACW1lNW8RSzt0z3MVB6ijpTHfYXfA2nqlgO9xGI0QZb29z3BwhzGzdzC8
1QFI+yNNDqoWWcGl951bQcBhGOh83OgdqOaktbsBNdM7xZBV087TVt5+rIiF
PTK7xuNCkcoBw48QTKk3PVjzeYU6BWJIqEOQr1KuKJezqKbzYZwjYSAPxtQo
9eG9yBwqs10VAeLTwUP8aLo51tRfRei6VYQoblbCbQElO2wuYOwLE18MsqMF
DsA9WmhXrigsFLoetfzg3C2A0oh7RPc0xGUFbMl0lfPxRphZBqlRipK/rHBF
1DgfeyNF+efbddHHS4hrQeIjGGKFarUVNQprtLZcF7UXYNiqsuv0fA6lAYyU
c2ncmkCrc02eyqVHxOC4My7LoHaiue1o9bdE50zqh98hohWBja1VorT3sZKt
BIFweOnERG+61YbhUskvXs7UaRY3kUBahwL0M04qj4gC/SxupaSFGuYISSQ5
FGgweIFvsy86rt8zNzERr8JGIY/iOcKKFNRyHN+3gaaRzmcmUy18uOeT0HsH
d55LoaVWRzC0h1040CPRkcRmjXaXKeQmbMvlWcVnjKqZRA2frQMyuivmdjuI
4vm8iqoaHyKUp6Rxr1wXL4EgQdfJVXxICrPaC006s4DG65h1csQdgEXDGddm
fs7X3p7G1w34W8iz+HoB9owDBRIMKqu9OWdhXO2hrCWKHzhYveyKftgt4svR
9AVGdylqLpvkr1S/LQ3B4Rtf6t6E1vuq0yxGA4iyvy091TUaI8jd3kkKxOw+
uTZCETG6fwz54v6kDDFlFLKHOko1UtI7MfDZXLvGymXGUaZLt9234d5JhTNv
7Zk0ZbMyPwDbysLKF0Sz08LLlYtOIERY4butCehCe75Fv5KpxFTXn6pE8Ynm
gzvPMRwglBoB5teXun4Olkgxwhe9Uvng6YB/CtXvODFEzKDzBfmrV8BoGwWm
2MFZU1UbLaN2wxHpbf0W5FAmRrKcuvACTJMopRyEUzA17cJsH14eDuwpNQfG
Zk+igyYhilHJNYIlnAmE2YI91NblXQClbBlMc+CNr9ye09zGjOb4yMWmbXKT
Fr7SHLjPGKto3SIYwVvvbeKl3r27MMQJS6FRG34FKtBytA+5BGxY4MUoAnGC
PKTomAM0PocSFNUUu8UUoH5Dp0Q161Oaq6egOA61lCMqsOBglYsD9B//9r+4
YSIUxVkTK8Pc32+Dptlak6sY+k5uJxy/lpcXCQTfrv/1XeenBtWNb4/UHekR
w7VrXERGHW+C02jGIETJwR/RrHH/f65vt5IxM0Tt4uqSC4JscZFT1Eu01+nl
ehDZcRmzGeN8A8Kom5aiUtK+jmLKNyTHgHQb7AKEoNNYC3SqBrg33Fay9xwf
tnVJ1atb7MRebgSzM0SXFpt94xKCDW7VhczkP4XKiXvMeFCOZe4YuJiiby70
5iHloIjF86Puvekq8f4CLAkOoBQ0aX9L3kADm5gdN3JORsXV43uoWBTxAY3P
MGndshK5ajpAIEOz/DICH01G7ngUODsS9+utGQEtSPDYSf/ZCOt043DKS996
KJ3FwmpVc3g118hj03nnHH8bNCooqcORYDuAsMU2zGFIgX/HV/9FBccqeDgN
F9OdLFfYI7Qi+EVmlakkIxlNdlPVC65LtkD63GgJadefmrvQJ4gw+FfOX+AV
XGe5wc8XGCEyiyuvcn+JHVvWB5KkVyk9usHD33Rr0c9x8L0VswWX2YkkSMRR
bMjUreY9284jce07w24ocRi2Xw2hst5yKyvXSuNRucGjC01P1d6BsXM3sWZ6
xgKdcvjuRSu6l9RSyxL663f2p4Xuql75xN7cK3EG+fThWelr0R/CfgJkW+N7
cklUA3lmT/dJ7lWapo8DEs9Nk+mEUil7XUlLpcgoQVtI6QHsb1ySy6cvhswS
ClHTEW6cBOzKvFr5jnxqlahXEdILGMOuf4OSlMsZwdwQEGhjz5iynntZoh0S
B57TUQ/8rfGbGSnZj9ArCkNgXOCCvjmfIIEgjlypmK6k8xKSnWnjGYt9wDMy
KvBk/jXFWu+jjfbF5JVetBFCFRI5iAPscXJrIk3n9KAwdC9ycsic2/8l/xBf
gBwxmkSlJQ+ytLwaM/7Y44E9JVAAqSC0J6RRmZUySnIGRo9B0H769OlDvia+
Y6/7LalcEqPwUmZ5wNKIz/Tg3oMHvsHzi+fvP76WECIXc6Au5PEj1IVoZLUY
9FDfOCl34YyytdHg0Cg/9eTRgyd+hPtPH/IIJnqTKxNFzo+gBqqnWA/6AH18
BSRvR8rTiskI0iZcLKAxeE0iSVwYzXWWgdKh98af87NBYsRk+wnER9M1mIa7
JlhY5S/5WecUTX3xYRKV6bHtIs/H9RpmVupgyb3A9DbzlpHgcrxxCCTKEwMa
+L4Zb1lwOEqrOelBHZae/Ave45NXD3Z9qAbErGPoneSKbuLmswsBO+tYu0H7
Y6BkjTEGyEbHxxiu7OktZtXbdPd8syNahDZhi7KQPgoZWshzJwlrDZRl73He
dx2gAjC/ggMBggak/+gyM5/wyxYjrTDJd02tzYotf5XW86M1BluVQzvLn++G
TNuUagNmrN9fOxeW47sKg8sYvSXzxe3ugnHpLw9vriGx5Eay+V4zSS2TmwHX
9LG1rlMFG0rXifiX0c309LiEOZ7lL3E8X+OkNGylfAh5CdKK872Q6g/kWM02
l2RjakA2vgRT7q/jkGnUGTW9xLOPOn/FRQZwkqY4wiO3DSVtcTMWS/iQNSM1
LeO3sH6qbB1NspOjL38SNWZlC/LIi8UX8XGcRtsZR2+MqaP4RHR/YBHuKXJS
fsNZZrIqendM0fNbrKK3EPhAvq2u20FvH2Lnbl1sDXdqeFnfjXOS9UPLqFmb
WrvT4STyRUzi7XxzH0nKRE0DDtqxJq2MNbLGV/AYeULfXyfQk3g3gZ9J6tk8
Ai+9nhe3uQfXPK3XUH2HghT5+gbw4AMD4xe3R5LA91M9ygdcCjEifVwgztvy
VqZiGjzzV2pZyMAzgmWkkoQhCUuT0/5lsUnclCe9yyoN/CoiSmJJKOCBEdzn
h31YRnWTvOJLneHS4O3P8ou4RF7xeOHedrwAF3DLc3EBeZ4yP78l371bcdLZ
sOdyU3qucHEJVrfaspHUNa/yTUVm1R7XCrz1h+ZZfm4iQLx1ZWo5VqVBJ2CO
06nnSiYbJAUDKkPgRB+JtcX3A+YWJUjc4Vq3UWJs6OZq7zxTfRluosKDZ3ox
rRwfeo240bE0Bx1xFhf616C4J2O7aQdDTvlbruS5QMgimQklaYdJD986or9F
4b5PDrLqmKIE1HB8ACIxNg7NZIfVDYU4YV5ajlP+JO8GT5Lx8yoPQsNq6xga
93rtnf0OB2oRN5UNLsFYFkcc21pn1XEnVUjEUtqrtP+8qMui66Ws3p0lgXdB
cg+ASlix3mdaYFlJeHy8S2IfWKnWZ7ux/qOaSQc9VIipZ26WFudI6RVNUoYW
pdzWMgBt4k6WSfMQbV4WBO+Rrk/qm2XAoydhJh+dYe40y/0Dig64V0J8p2/V
ZNZp09e5JKkQ7pAnl20V4pFOuApcbTzQ98ZluOzSWXsw7fXCrq7cZa7toeQy
FgnIqTnpUSOsmP09g6o7vPFnZf+69ln+WsvkuNogdJLtK+nyzNG4f67QLr+l
0M4Xotj1vEmIrM/v9I6Ms1CHdqpxdBVgoZTU2o/xNaGCRgPAGQA0drdxZgNy
Xws2ki0Mm5vpdgrhFZflX8kHd+3Vzayfkc7lpqbKvj6OGUUPfD0YJ7jU25Ge
jnJvVzdwcFURWdkBIuv/pSNx5Dr4uB+BuFUaXwmRC3/Jcwau8MEk4kEELyc+
hBBaO8o7xi+iMV5AVjIpMnv+MstmMxYSl9BWONsvYhhLb1WZKQpWIbtyY5km
QH2In7VJcqulXBxrdYbLYgEpghj8SHIlejI4xqFIxacNpOsTX6F6RX7rgnFc
vnypt3chHRNal9NrJu3Sj71E0itcbjnQ25QNdrbrkJVgZEEMi4/i51W/6yOg
moHWLd7D2x+yBLjhMllWenuZXSYz0LfMo1rMEZB50vKU4diOAW3sdMJatUvo
c7tLKB5a47PFfMcGvEyk4s2ydNEqPU31anaNt8z3oQhdcHauU6MCNzaSpO/l
RjIjkMkimTdt915IE8XRFSg9QzIaxz2YzGBNLoojZXGliSRPprj9P9+bE+Gc
5Gp4u3smNF7jooyYiyPOM/Sev07O8xjW75eK0v6urKUvO612L1hAvT5JU14x
Pk26FUsLTHbVb4f02dVuaZXgQWL0NkTaxBqgtW1pdUpGZr1YDjtpfEt2CIr5
V1aQ+l1+cfbu7EA6sBlWtoud3SUImBH/Ujv8oxByOp0yMB2jnC1woULtypUg
yL4+k5bHrvwfJ0viDnfyh95yylcsadP1HS6U8nBX61pr1+6Yp2zLgAsbWQ0A
PAryR8cBcowHYXAxnyRRE3fQmIeU/ynRYrsu5m7gq8fkJ6hNKLqh91T38/ke
ogyLVEgZUakwNvoioE1t67YgK7y/mjpRCONeIsmm9dJy/7/WD44Fccj+h34k
HkSHypsJo5GFIy7Onuu9qbP8M8BbtlfqI2z5KiLLnnK9hd8HSOAbxtCzDgJ5
1SIu2amK7kWdZf8XlhGaitK/AAA=

-->

</rfc>
