<?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.39 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-miao-agw-core-functional-architecture-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.0 -->
  <front>
    <title abbrev="Agent Gateway Core functional Architecture ">Agent Gateway Core functional Architecture</title>
    <seriesInfo name="Internet-Draft" value="draft-miao-agw-core-functional-architecture-00"/>
    <author initials="C." surname="Miao" fullname="Chuanyang Miao">
      <organization>ZTE Corporation</organization>
      <address>
        <email>yuan.dongyu@zte.com.cn</email>
      </address>
    </author>
    <author initials="R." surname="Chen" fullname="Ran Chen">
      <organization>ZTE Corporation</organization>
      <address>
        <email>chen.ran@zte.com.cn</email>
      </address>
    </author>
    <author initials="J." surname="Yan" fullname="Jinjie Yan">
      <organization>ZTE Corporation</organization>
      <address>
        <email>yan.jinjie@zte.com.cn</email>
      </address>
    </author>
    <date year="2026" month="June" day="25"/>
    <abstract>
      <?line 36?>

<t>This document defines the core functional architecture of the Agent Gateway as a universal infrastructure component. The Agent Gateway is designed to address key challenges in single-domain multi-agent collaboration and cross-domain multi-agent communication, including trust boundaries, protocol termination, capability discovery, and task routing. The main framework consists of four gateway capabilities: the A2A Gateway (supporting inter-agent communication), the MCP Gateway (supporting tool invocation), the Model Routing Gateway (supporting large language model invocation), and the Network Gateway (supporting underlying network connectivity). The A2A Gateway is further decomposed into five core capabilities: protocol translation, authentication and security, asynchronous task management, peer-to-peer network management, and Agent routing capabilities (including Agent registry, capability discovery, task routing, and load balancing). This document is intended for designers and implementers seeking to build standardized, interoperable agent communication infrastructure.</t>
    </abstract>
  </front>
  <middle>
    <?line 41?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>As agent technology evolves from single-device intelligence to multi-device collaboration and cross-domain interconnection, there is a growing demand for inter-agent communication across home, vehicle, and enterprise campus scenarios. Typical use cases include:</t>
      <t>Traffic lanes, for instance, have emerged and been commonly used for</t>
      <ul spacing="normal">
        <li>
          <t>Single-domain multi-agent collaboration: Within the same home domain, a lighting agent, security agent, and environment agent collaborate to execute an "away mode" scene;</t>
        </li>
        <li>
          <t>Cross-domain agent communication: A vehicle agent interacts with a home agent across domains to enable "auto-arm when leaving, pre-condition when approaching";</t>
        </li>
        <li>
          <t>Cross-vendor agent interoperability: Agents from different brands (e.g., Midea Home Agent and Huawei Vehicle Agent) need to cooperate across trust domains.</t>
        </li>
      </ul>
      <t>Existing agent communication architectures lack a standardized cross-domain trust boundary and protocol termination layer. To address this problem, this document proposes the Agent Gateway as a unified infrastructure component and defines its core functional architecture. This architecture covers four categories of gateway capabilities, corresponding to inter-agent communication, tool invocation, large model routing, and network connectivity, thereby forming a complete end-to-end agent communication middleware.</t>
    </section>
    <section anchor="conventions">
      <name>Conventions Used in This Document</name>
      <section anchor="abbreviations">
        <name>Abbreviations</name>
        <ul spacing="normal">
          <li>
            <t>AGW: Agent Gateway</t>
          </li>
          <li>
            <t>QoE: Quality of Experience.</t>
          </li>
          <li>
            <t>SLA: Service Level Agreement.</t>
          </li>
          <li>
            <t>SRv6: Segment Routing over IPv6.</t>
          </li>
        </ul>
      </section>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
   capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="AGW-frame">
      <name>Agent Gateway Main Framework</name>
      <t>The overall architecture of the Agent Gateway consists of four logical sub-gateways. They may be deployed on the same physical node or distributed across multiple nodes. Each sub-gateway has clearly defined responsibilities and standardized interfaces, collectively providing unified ingress and egress control.</t>
      <artwork><![CDATA[
  +----------------------------------------------------------------+
  |                      Agent Gateway                             |
  |                                                                |
  |  +------------------+  +------------------+                    |
  |  |   A2A Gateway    |  |   MCP Gateway    |                    |
  |  | (Inter-Agent     |  | (Tool Invocation)|                    |
  |  |  Communication)  |  |                  |                    |
  |  +--------+---------+  +--------+---------+                    |
  |           |                     |                              |
  |  +--------+---------+  +--------+---------+                    |
  |  | Model Routing    |  |  Network Gateway |                    |
  |  | Gateway          |  | (Network         |                    |
  |  | (LLM Invocation) |  |  Connectivity)   |                    |
  |  +------------------+  +------------------+                    |
  |                                                                |
  +----------------------------------------------------------------+

]]></artwork>
      <t>The following subsections describe the functions of each sub-gateway.</t>
      <section anchor="a2a-gateway-inter-agent-communication">
        <name>A2A Gateway: Inter-Agent Communication</name>
        <t>The A2A Gateway is the core of the Agent Gateway. It is responsible for handling inter-agent connectivity, discovery, task routing, and security management. It exposes standardized A2A protocol endpoints externally (e.g., /.well-known/agent.jsonand POST /a2a/tasks) and connects internally to sub-agents or upstream Supervisor Agents. The A2A Gateway comprises the following five core capabilities:</t>
        <section anchor="protocol-translation">
          <name>Protocol Translation</name>
          <ul spacing="normal">
            <li>
              <t>Description: Translates external A2A requests (HTTP/HTTPS, WebSocket, gRPC, etc.) into commands understandable by internal agents (e.g., local MQTT, DDS, soft bus messages), and vice versa;</t>
            </li>
            <li>
              <t>Applicable Scenarios: Bridging external protocols with internal proprietary protocols during cross-domain agent communication; unifying protocols across different subsystems (ZigBee, BLE, Wi-Fi) within a single domain;</t>
            </li>
            <li>
              <t>Design Considerations: Support plugin-based protocol adapters to allow dynamic loading of new transport protocols and serialization formats (JSON, Protobuf, CBOR).</t>
            </li>
          </ul>
        </section>
        <section anchor="authentication-and-security">
          <name>Authentication and Security</name>
          <ul spacing="normal">
            <li>
              <t>Description: Performs identity verification and authorization checks on all incoming requests to the A2A Gateway. Supports OAuth 2.0 Device Flow, JWT issuance and verification, and Scope whitelisting. For cross-domain requests, mutual TLS (mTLS) or Federation-based trust relationships must be established;</t>
            </li>
            <li>
              <t>Applicable Scenarios: Mandatory identity verification for cross-domain calls; optional within a single domain to prevent malicious nodes from impersonating legitimate agents;</t>
            </li>
            <li>
              <t>Design Considerations: Built-in Certificate Revocation List (CRL) caching; support for Human-in-the-Loop (HITL) triggering of secondary confirmation for highly sensitive operations (e.g., unlocking a door).</t>
            </li>
          </ul>
        </section>
        <section anchor="asynchronous-task-management">
          <name>Asynchronous Task Management</name>
          <ul spacing="normal">
            <li>
              <t>Description: Manages the lifecycle of all tasks passing through the A2A Gateway, including task creation, status tracking, result delivery, and timeout handling. Follows the Task object model defined in the Google A2A protocol (task_id, status, artifacts, messages);</t>
            </li>
            <li>
              <t>Applicable Scenarios: Long-running agent collaboration tasks (e.g., "whole-house cleaning" requiring sequential execution by multiple agents); cross-domain tasks that may require asynchronous waiting due to network latency;</t>
            </li>
            <li>
              <t>Design Considerations: Support persistent task queues (SQLite/LevelDB); provide two result notification methods: callback URL or WebSocket push; support task cancellation and pause/resume.</t>
            </li>
          </ul>
        </section>
        <section anchor="peer-to-peer-network-management">
          <name>Peer-to-Peer Network Management</name>
          <ul spacing="normal">
            <li>
              <t>Description: Manages peer connections with other domain Agent Gateways. Includes NAT traversal (STUN/TURN/ICE), reverse channel maintenance (WebSocket/MQTT long-lived connections), heartbeat keep-alive, and reconnection strategies;</t>
            </li>
            <li>
              <t>Applicable Scenarios: Between a home domain Gateway and a cloud Relay Gateway; between a home domain Gateway and a vehicle domain Gateway;</t>
            </li>
            <li>
              <t>Design Considerations: Support both active connection initiation and passive acceptance modes; provide connection quality monitoring and automatic switchover to backup paths.</t>
            </li>
          </ul>
        </section>
        <section anchor="agent-routing-capabilities">
          <name>Agent Routing Capabilities</name>
          <t>Agent routing capabilities form the intelligent scheduling module within the A2A Gateway, comprising the following sub-functions:</t>
          <ul spacing="normal">
            <li>
              <t>Agent Registry: Receives registration information (Agent ID, Skill list, address, protocol type) from all agents within the domain, forming a domain-wide agent directory. Supports dynamic registration/deregistration and automatic removal upon heartbeat timeout.</t>
            </li>
            <li>
              <t>Agent Capability Discovery: Exposes an aggregated Agent Card externally (/.well-known/agent.json), hiding internal topology; provides capability query interfaces internally for other agents or upper-layer orchestration engines to search for available Skills.</t>
            </li>
            <li>
              <t>Agent Task Routing: Distributes tasks to the correct agent instance based on the target Skill ID or intent matching. Supports content-based routing (e.g., by device type or zone) and weight-based routing.</t>
            </li>
            <li>
              <t>Load Balancing: When multiple agent instances provide the same Skill (e.g., redundant backups), distributes tasks according to predefined policies (round-robin, least connections, consistent hashing) to improve availability.</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="mcp-gateway-tool-invocation">
        <name>MCP Gateway: Tool Invocation</name>
        <t>The MCP (Model Context Protocol) Gateway is responsible for managing the registration, discovery, and invocation of external tools. It provides a unified way for agents to invoke non-agent services or device capabilities, such as:</t>
        <ul spacing="normal">
          <li>
            <t>Calling a weather API to retrieve real-time data;</t>
          </li>
          <li>
            <t>Controlling IoT devices that do not possess full agent capabilities (via device SDKs);</t>
          </li>
          <li>
            <t>Accessing databases or file systems.</t>
          </li>
        </ul>
        <t>Core Functions:</t>
        <ul spacing="normal">
          <li>
            <t>Tool Registration and Metadata Management: Receives tool provider Schema registrations (compliant with MCP Tool Schema specification), including input parameters, output format, and authentication requirements.</t>
          </li>
          <li>
            <t>Tool Invocation Proxy: Forwards tool invocation requests initiated by agents to the corresponding tool backend and returns results to the agent. Supports both synchronous and asynchronous modes.</t>
          </li>
          <li>
            <t>Security Sandbox: Performs permission checks (whether the caller is authorized to use the tool), rate limiting, and input filtering for tool invocations to prevent malicious injection.</t>
          </li>
          <li>
            <t>Tool Chaining: Supports composing multiple tools into composite tools, simplifying orchestration logic on the agent side.</t>
          </li>
        </ul>
        <t>Relationship between the MCP Gateway and the A2A Gateway: The A2A Gateway handles agent-to-agent communication; the MCP Gateway handles agent-to-tool communication. Both may share common infrastructure services such as authentication and logging within the Agent Gateway.</t>
      </section>
      <section anchor="model-routing-gateway-large-language-model-invocation">
        <name>Model Routing Gateway: Large Language Model Invocation</name>
        <t>The Model Routing Gateway provides a unified entry point for agents to invoke large language models (LLMs), enabling model selection, load balancing, and cost control.</t>
        <t>Core Functions:</t>
        <ul spacing="normal">
          <li>
            <t>Model Registration and Routing: Maintains a list of available models (e.g., Hunyuan, DeepSeek, GPT-4o, etc.) and routes requests to the most suitable model instance based on model preference, task type (reasoning, generation, translation), token budget, and other factors.</t>
          </li>
          <li>
            <t>Unified API Adaptation: Converts vendor-specific APIs (OpenAI-compatible format, Hunyuan API, Claude API, etc.) into a standard interface (e.g., OpenAI Chat Completion format), reducing integration complexity for agents.</t>
          </li>
          <li>
            <t>Context Management and Caching: Implements semantic caching for frequently occurring requests (e.g., common knowledge queries) to reduce duplicate invocations; supports sliding window context truncation to control token consumption.</t>
          </li>
          <li>
            <t>Security and Compliance: Performs content filtering on model outputs (sensitive word detection, privacy leakage detection); records audit logs for compliance purposes.</t>
          </li>
        </ul>
        <t>The Model Routing Gateway is typically deployed in the cloud or at the edge. It works in conjunction with the A2A Gateway: agents delegate inference tasks to the Model Routing Gateway via the A2A Gateway, which then invokes the specific LLM.</t>
      </section>
      <section anchor="network-gateway-network-connectivity">
        <name>Network Gateway: Network Connectivity</name>
        <t>The Network Gateway provides underlying network connection management capabilities, ensuring that the Agent Gateway can stably access the internet and communicate with external entities.</t>
        <t>Core Functions:</t>
        <ul spacing="normal">
          <li>
            <t>Connection Management: Manages the connection state of multiple network links (Ethernet, Wi-Fi, cellular), supporting primary/backup switching and failover.</t>
          </li>
          <li>
            <t>NAT Traversal: Integrates STUN/TURN/ICE clients to provide underlying P2P capabilities for peer-to-peer network management; relays traffic via TURN when no public IP is available.</t>
          </li>
          <li>
            <t>Firewall and Port Mapping: Automatically configures UPnP or manual port forwarding rules so that external A2A requests can reach the Gateway's listening ports.</t>
          </li>
          <li>
            <t>Quality of Service (QoS): Assigns priority levels to different types of traffic (control commands, media streams, bulk data) to ensure low latency for critical tasks.</t>
          </li>
          <li>
            <t>Network Diagnostics: Provides diagnostic tools such as connectivity testing, bandwidth measurement, and packet loss statistics to assist operations and maintenance.</t>
          </li>
        </ul>
        <t>The Network Gateway typically runs on home routers, edge servers, or cloud hosts, serving as the bridge between the Agent Gateway and the physical network.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>As the sole entry point for cross-domain communication, the Agent Gateway must enforce strict security measures:</t>
      <ul spacing="normal">
        <li>
          <t>All external interfaces MUST use TLS 1.3 encryption;</t>
        </li>
        <li>
          <t>Authentication tokens SHOULD have a limited validity period (recommended no more than 24 hours) and support refresh;</t>
        </li>
        <li>
          <t>Cross-domain requests MUST pass mTLS or Federation-level cascading trust verification;</t>
        </li>
        <li>
          <t>Highly sensitive operations (e.g., door lock control) MUST enable the HITL mechanism, and HITL confirmation requests SHOULD be delivered to the user through an independent channel (e.g., mobile push notification);</t>
        </li>
        <li>
          <t>All gateway components SHOULD record complete audit logs, including request source, target, operation, result, and timestamp. Logs MUST be tamper-proof.</t>
        </li>
      </ul>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>TBA.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>TBA.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC6749">
          <front>
            <title>The OAuth 2.0 Authorization Framework</title>
            <author fullname="D. Hardt" initials="D." role="editor" surname="Hardt"/>
            <date month="October" year="2012"/>
            <abstract>
              <t>The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6749"/>
          <seriesInfo name="DOI" value="10.17487/RFC6749"/>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC5246">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
            <author fullname="T. Dierks" initials="T." surname="Dierks"/>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2008"/>
            <abstract>
              <t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5246"/>
          <seriesInfo name="DOI" value="10.17487/RFC5246"/>
        </reference>
        <reference anchor="RFC5389">
          <front>
            <title>Session Traversal Utilities for NAT (STUN)</title>
            <author fullname="J. Rosenberg" initials="J." surname="Rosenberg"/>
            <author fullname="R. Mahy" initials="R." surname="Mahy"/>
            <author fullname="P. Matthews" initials="P." surname="Matthews"/>
            <author fullname="D. Wing" initials="D." surname="Wing"/>
            <date month="October" year="2008"/>
            <abstract>
              <t>Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them.</t>
              <t>STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution.</t>
              <t>This document obsoletes RFC 3489. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5389"/>
          <seriesInfo name="DOI" value="10.17487/RFC5389"/>
        </reference>
        <reference anchor="RFC5776">
          <front>
            <title>Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols</title>
            <author fullname="V. Roca" initials="V." surname="Roca"/>
            <author fullname="A. Francillon" initials="A." surname="Francillon"/>
            <author fullname="S. Faurite" initials="S." surname="Faurite"/>
            <date month="April" year="2010"/>
            <abstract>
              <t>This document details the Timed Efficient Stream \%Loss-Tolerant Authentication (TESLA) packet source authentication and packet integrity verification protocol and its integration within the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) content delivery protocols. This document only considers the authentication/integrity verification of the packets generated by the session's sender. The authentication and integrity verification of the packets sent by receivers, if any, is out of the scope of this document. This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5776"/>
          <seriesInfo name="DOI" value="10.17487/RFC5776"/>
        </reference>
      </references>
    </references>
    <?line 232?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA61bbXPbOJL+nqr8B5Tz4ayLJE8y2cyeUnV1iuxMPGsnjq1c
avfLFURCEmKS4BKkFE1m5rff0w2ABGU5ztZOaiqRKBJs9MvTT3djRqPR40eb
ifjx8aPUJIXM1USklVzWo1xLM5Kr7SgxlRotmyKptSlkNpJVsta1SuoG13/4
4fGjRNYTYev08SPbLHJtLe6rdyVWOj+bv3n8qNZ1hi/TlSpq8bOs1VbuxAyr
im5VMY1WFY8fycWiUpDrvx8/Ev/Ck48fbVcTPI4Fmnptqgl9HAm3r9m6kcVO
Fitxib3RwqbC3f+Yn9GapakkrUjXVS51NhE73D9OTbHaNf/za63GicnHSSEE
3dItey0LLK2K71gwwW3jSha91YQQsZS/6OKzVuLv8nsWxG7Gn/mBvSXpHvxV
mCrHMxs14QvXb2bPnz37r/bLX5/99KL98vKnF9EvL168ZOXpYnlnjb885x/9
lx//2j32l59+ejkJGxqNhFzYupJJTd/na20FnKzJyZqpWupCWVGvlUj2LBp7
mDBLvqfvA9IKKZoCQlUWD0DISuJNjXsEaihNgfvHYn7nURJCWb0qVCpqI2Sa
Vspacat2MI/MMlWsIJYuhNXFKlOj1EDVhcibrNaIB1oqMVkmF94aQhapSCpj
7eFb8xxyJnzrEMsmWZNiYQFhbS0WpilSWWllh6KsTG2wtKhVlevCP5HIUi50
puudSLVNDHa8G/I7a2lvRWWaGsu5jfLboYlcbU11i3cXVtvakgqXpqnEyqug
XRPvnTjtPp+2Cjq2TQlXo2UhL4Q5tJXBkJ+7nF0dfK42hqyyMf27Taoyce1E
PvhcJquVwt/FqsFLRc4P9NbhnWOtd6rmTR5aBTpVVbajj4W/Dboo4FB6A0UO
vFtEe4ZTLJsK61ZwDnYfC/fA7o1Ywsmch/bV1pkLAW0zby6CHSjLa4mltSpp
KrwWP9pdkawrU5jGOvPlssA+KSBgfwVV12ZE/7ZyxzfQYs6XvdV7Eonjzrn8
XWoF85O7HHai2IHc6pmRqVhI6D/BNdZTHLPaskNAuykcqgpxVFl+WOdlxpLS
BavUrXMEsWh0Bi3Ukjw91b+qdOj8ypSqkotMiQP+tRfSY0YUhym5TtNM0bcn
4ryoK5M2DBzi6xMdff2d7gAUTa1fH4CyLkxmVjuhNibbQGXLyuRtnKuNThRL
lmUaT+ALpHfB7H98IPB5V8HTyBvIoRSpTYpVZbakkBTIXTj13RtcQvKyYm1y
NRQbtdZJppyFWL1lpS25Y17Cj2yiCiCIsbDWrsQKmWj4V8swRi6hJl4Xc2T2
pU4owAhxnBBkmQTLryUcHQZEBKb8roVSBQtmimxHi7LYfqn/FOLm+wByIj7p
eo07KGwtwIn3Jdxj2JWAttfszvzwsA2Y8N3te6MROOyG++9gO6kveAofkYyP
JIU0YccRa0e96mSexfY6oHrQlKBw/zNbCSnMii22AXFZevebt5NbzrIYBXv0
EXAA7KnKxRZwIDIlNxxkJSgTHCTVbGb+TZZAEomEV6yO7gi6QbDBSJEkLmg4
lj2l8m6c6uUS3ob7FgCkFHigxqvxEFwnVVK8JaEdLJA63zZyq7T4X79T/mEA
0HE5MTH8FtKm26BLVn6bYy/k2RegS2u2fQ+OUriFvyW30FyMAf3I6WXDHYt4
KB1ioZ2q4Ohd3q4JoXAvtJ4P3bcWr3CZgNx+g0AsNeP8YfrAcgSioqHobxEV
D5Y97sJIa13yhWLUylCqp3x8KBUPaX1sqiQHcdh5L0QM91Ps0OdOlzJ7qH4o
B3psWuwopHO2Iu87U7A6nI4SEf45aFsHwFuJPTsUnpliQ0kPfEN8dInTKeM0
WOLrk6S7h5H5yRMxZY6veVHbef705097xUL32wdzNhEfGsmpDGo8+wJH1YTV
4wiXLqYTcaMqhuwLtYE+pqtKcW6Kb7vevKT7VixhYCVkMXF+tXk59lJeq382
uuKHrbjwzCTgKfyKiCPUi4A7uvx4Mz8aun/Fu/f8+frsw8fz67NT+nzzdnpx
0X5wd/A6uPD+44W/hz51T8/eX16evTt1C+Cq2Lt0Of37EZvZLfT+an7+/t30
4kgw4MbRAHtxOnY5DkkEpk4pEJDGk0ovnN1ez654pWcvxNevvl74/Xf3mcoF
fCbYcp7FicF9hTvtCMuUpJwiQKR5Gfi3rmVmifwIuzbbQpDfecfpx+QlIcGb
lr5+fQJPGDGd/d3VD4qtg6W/o0K4Q36R+Dk5okYd+eizTASRKnA/1JKqMjM7
RdvqclW53ll+rkBgCSI9xKn0omHlOXjk1IfQ4Xuw6BngPH4PUiuwA0kApNTj
SSpcoFvd8jfmijFCspmWMnHIgMqEYldhCeDaRqeO6QYEWzEacqp0H6EAkKFs
7IjTH3/84Xz26ejf/POUVvlNHPzTN8G3/vz2jVW+/09Y5cCmnt539f5VSJy4
KBDt1bjMEffI3a1yfM6o7ZTRrnI8J8A+72qZB1YBqsb1VivL/gPfpZenB/Xy
9Pv08u13PWTFP1eW3/aKSBH0sl8PPqDdOz7qbBRW+ebeIktfXFzGJm0tFxWb
D63y5/juv/fntz8LGTzQUAOI4HoJ1HJlD9DQuqqoyzcMsoFNMVCrPeAMOTiK
yomIo6sXIyFJ7BX2bYfpUJ4Yi3Oua1s0zhSXRWsgaXa3AxITqG9W0m0N0xXw
/Cr1xTHSHtCTwC3dBesqjSayob7g1aCZQHzP5U/GWxSno9sCefSEZRp/tmCi
eOHVe3COE/lcnpAwduCqUyewK9v9UqAApGHpSgdstSmR0JTMxU1TEmmyuOYK
i7t9EqKIVHw6rXbmvadJ4sz3RFyFzc27XklHxE7ZH0pXfoU7VLd/lqACDVOU
z4/fzudXJ/TXzVB8Uosbk9wqVImr66vZUKg6GQ9c44ZIKxdC3A5yCifzgvMG
dQivBa/ezFCiv/wwnw/F6SmWt2aJqgRFdo6Minutb0Axs+TeY1SxTcsygyfS
K25CTT4RryudrkhF7W6CpX1B2cpC1Qq4bE0FUHdPCjeiTs8DdesrpgLc8uqe
DeVpWxlSFO5srXJs+R969Vqh7H99cQY96tEbPWCBaH3fE/EV36ueqfSqIICz
KCtdfY9N3rjemyizBnsdLSQVAa1Hy1SW3BSidit5jEh3hcypD2Ek0xhEZqG2
rpPmFur2wMFUaVD+X1354frR2MEvN+/fDZ1vLZrlUMxev78ejIPPTe924m58
UN7jeldgW1gb0ZLSgwhemBj8KlrBTRWCJMlaJbeW6CJxUl3AIrSb1lWx373m
6jioyor3JKB4Pv4BQrA/vYFmhuKXT3PgkW2oJ+N8LZLBed9NgvIctBsEOHMl
+Fi8QdD2fCQIMQQ7rVEwifnFjTjO8feAgv6NCubz1nIVeKVccNq1LonXUlGO
ehDBs8Cr1ip90N8vKcxqAx8+rMXlvqAIucy+Eqb0NfVhHyRdomKhEhKQivdq
6qEy33btD50DvAgLXR9ZrYBAObcwOMQf9uHXjc7qEd40U1Xt5FUo/kJuFxdQ
tTieXV8MIDK3a14J33PmTb1tgDZ4fgSTjy6MKYFU53PcjWphtVKV93MkBuOa
HPh3qXm04tWy1qs1ANoqCEZMX7guDCdHj1BNAYy6deV6akwVuXvcW55TPrps
M889/u5ucFCe6aVKdtQLgozkzZxFRCmt5VYEVm5W63137g006J0JEolzVLhM
TV3uSrK8Q8qwKJOQ/DMdzTB0rpA223RLjkwI4YTibZjFZ6Qw39cIxZPvJv5s
DLlIL38ekyD/p9MgAl5E9qQO3rDD8Qf9+MIUq1HVFEXc4Yq7v05B3i5H27XJ
1GhtuPWKSo8eO+Ig1Gx5S+GIcICDu04lLYFM1JaOzk0Hr/b6YvySei1rLlLd
eqo/SNhKzT6fNlzfh24P5dAi2f0L4I34gY9zq5wUD4EbGivcfLgA0pxwI+X0
NSR05SdetjXBqoWpuxDPFUAyxcoU2gtq/X28viDQabO1KBu77sLHuQ4hXpZ1
WFtKKPOEXpCr1s2v/JCE/m05/3d7Oo9Wuga9z8DGzX2cxnvsEAzo3HXQrXg3
nZM3+4nj8c3847uT+cfrdyfns7MBuTf9omiGiOUznsVBlwzjx+3GT4hcIO3B
tygM0lgYLLJW8NUFQkjcKlWOJN3jAqVS3Z2CZqo1EE7Zh+kHVERtfBk33bsu
KKU0+KtpUkBdhiv+l1eA/YcfDI3y/o/f73ELQw117mpEikBww6FjPwAGbagX
naiSZxUMBrZzxOjZf/reYG6wiOHQ83nbENImwsLkyZq7fNQMg3c2JV5Rr20H
pau4ITiLCC3d8Y0JHLEHxqVuiATOBZaQNlxLQOwG6tp245Aelnpy7fB2r3hq
D2DYSWRyJ6gf803wKVGa5lp+8tdO0kxIM8fukfPTobi51YB5IhDD0EyPZ9C7
Ug1cZuV+m+PJkeRhfNO1j92V0ZYs4gAzBVYlxAUi2hOoXyziCXwjlrhvsUrl
ZkNTLRRoUYT41DHeV8esm3WehgptQo1irrsksecV3iapfxeeqNJesXVPmUUB
6tpuLWevTckTxdYXbTxrBYJWu6iNF5dhlPAd8MSVGDB4xDMOfIXftBpRxcqd
lkDxpqj5yc/LjdSZi3gypr2jC06g3pEnpA7fubQhsZhQHZOh2jGTmwgKRwx9
M7Sm6ULtveb8VPj5JdOxmulQZGTqPeInTy1DrPhcuaAeKDNecjJa6FdTKFew
bhXNAvvPjf1ZFrexCxpRvw4j6on4RDO0fhZtd2C7VBXauU5+L0mFwAQXo5EZ
4wBBcHpHScAdU4WBDDho4CCwPGgoZciK5lajyiwoIJD8bR3j+jD0okm0tbSk
qwEPd3ISTwUzss+EjkfUcURN3O8cRsMHuu3YdcRmpPMvdVtrD+IeyH57g7sS
AWji2BvunzLpJkzcoPnSOj6KM+5otI7fzdPopUvTejbPsTbmlvrjhW+lWDee
YbcPw/XeKMw2cHJJaNeafobAcVCzBQBQ6Eyvzmn1SsFkyL/4ILMRAYNADRLX
5jPXDOfHz83cv9Izq9QQf4E9raXG+bIJgLd3vmKjZZD15vRvfQ6J3OSYMr14
wbN37GypoW9fcdMRBvzHp9fe9MA8LMJmvt4HwktVS1o0YjkR0vMU0JugQuJf
q1z2DAq5ea6nyc2Z7pDP8Kv83bZUSUveBjGl10UJbl5KGsFQAT8UiEi65BLK
sC2Jozq7isZl/cjd82Jy1C9wblSuW0njs72BZldGez4Ax1rsIp9qkSsamGIF
CmWeXDJrqpuqsJ6ltk85SO/ginlITKl5X/EFJhz97YRmgrjB3QvzJeoflDSx
5mOQoUVwvF0r9lgWmk6ZVXwsxLcT3NidageGWmyDGCUVoJnOdddVdAaBV9Wu
nqQg21ObPVwp6+Kzg6MDNpmtkbcZTCMApyNQzFkCtHLEt501+rX2FxGsdPbH
t5/6iYunbiGH+NCHqzLMXUfNhpZv7p8qC+e9ei3g/bYkl4/KH/Sh8uBgh2x/
6TtPsSp7D43Fa/INqr3sWrqzAfmd00kdmnnUOnQMDJpgxI3ZX68THZD/0CE5
1KM83Q/zZ39XPyfM7z1idwCj8WbqM1Kn+TBWHzqKZ3niQWmSz7l4TosXWpWF
M0/9M2RD34d2KbEdSB5AQeeQXv59EGw5DM2Iaz5sI5m7cruipUFBSJfe3zYF
neAdogxR5Y1St0Px89V89MKENjFDhOFUv9+zy0li2+i6W/cAMXLXEW3cX6VD
VFzKMq85RjICaWQdQLcq5NfouCAdi4SqC7Fo0pXyeOpIIfUrTLUHOR+97Sjt
Tamp6o8s8fkLClt3XGgUEJ1uhDbel6qYno8oavGApwCM315DdN9QzDKJQtd9
jtro3bGdjskGDbuVCUB4FEOnR7oO7cARrCQQ5pW3pztm8oWgs3O8/kYDl+lS
Hqtm5vpuE3EejhrSQUNwGSoTfFOO11xWrt0Cnm0SwHTVa8t64X0oE8vPFPTP
dB2JfuAoBSQHjWi4qK5VjLBt4wJvz1xBgDItNVvHeyE3gKHwoc9wyY7vbU1k
sMnLu1jcJhTeqs/ZiYryiqfVUQJofdAlZuyt6x7SoRTwlToEJmrLjUx2RFBv
KaLbnwavuL1AORgeoGuCKusata0UomwqrqDG30Yamre5U4h81MEfqPB45xoN
ZPOav5PWmUNSF4fPXGOHnz0qOLJyB/o9TuHdXMMRErvY65c0h6UjBnen7N6u
dcIvKjz0ueZjG0RAvIDNe0PmSXshnvgGBe1PpFsQ/sbxZLJn5/N9RgzDulkQ
k9YDJ14kdYaAVztulVjbtiIqvMbjcMhtrgvR8Xlu1Wtv3nvRedaJGbPRuJHc
a1PRewDQ3fmY0JvUBZGiM4K6goCP508ISZTdDRLPYCii49xw3FxWuxPfrHEd
nNDZWQL7qVzpxxI16+ahWedGxgQ/kLHXt4NH6pD2QqkYWefq+dWdBs9Dx7Rf
8Qxlx51vPmtLPkfvc6c9C7yoQeZMxPkVM8CQu/ryvwGF3nLjhUa71Cu7lGXJ
2DcNjREOMR4irPiQ5cer4kq42o7mPWEwQeSa4a8hrmONc5/Ds1VyoYqH8Nxd
d471H5YzreJOOMNeX9boOF44dHf8wdwMIKql9h9V4dowsmXUQ2ZtdzNJSpY8
/A8KOw54GQa41LZPNeUhGlPj66LJbrnQGrgjt5Y4GM0Vfc/bD5k0K8nhwp57
eLOdarkqkOl1YidUj7j4TNurnvQGVhfP/wWcyRHzBWTc6pRoIjJ+U0Wn9UvJ
3e6MprAUDZpfxXNQa5m9dBMeuj9qGo/vg5EOXpFkePjIDVrmMVSicSojQuoK
tsqj7trwMJCZKoWOi9YFTadVj3zvnZP19Ls7BufE8cfKnnRZq9/kFV+fhCMQ
o6T3C5/lm3qMNZm6w0T708G9Q693BOQZpaIWJ/yOWjdJHR2+cAbp9UyzrHP+
qDXHZzapAqM56bPxj1gzqXacpl/1fGdvrsxJHbDijm3yGXrpqjbkvY0kfgBB
6JSqSYkT0obc/0EBKMgJaBGPhXj+AhZqKn9uIwxGQCwh/bovwOzQmNfJT61y
QTPevREvxx39LwGJjP7no3gu23/F24cnkTR9pAMTt4HeDJwI/gA8GYrGnzAB
TUS0zV1E8LXe5LPdgVchH8TkGaGrimkl2KVqZ5CS8jSoBWmRkqQfuHi5crOg
pgsNmHpTqcGeFeEG7RnscN67lcHRoe5AdEeL4vaIlxxe3FSO+1fM4ltlhaFn
N+sECOTlWFwQwWJ10SkoSaPrEfKPWTqY4j98PjZp2SmzXSDC66k/O3s+fTe9
G3Qga/JQwIXnRqMRd0geP/p/Qxnn6vo5AAA=

-->

</rfc>
