1220 lines
52 KiB
XML
1220 lines
52 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
||
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
|
||
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.31 (Ruby 3.4.8) -->
|
||
|
||
|
||
<!DOCTYPE rfc [
|
||
<!ENTITY nbsp " ">
|
||
<!ENTITY zwsp "​">
|
||
<!ENTITY nbhy "‑">
|
||
<!ENTITY wj "⁠">
|
||
|
||
]>
|
||
|
||
|
||
<rfc ipr="trust200902" docName="draft-nennemann-agent-federation-privacy-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
|
||
<front>
|
||
<title abbrev="Agent Federation Privacy">Federated Agent Learning Privacy and Cross-Protocol Migration</title>
|
||
|
||
<author fullname="Christian Nennemann">
|
||
<organization>Independent Researcher</organization>
|
||
<address>
|
||
<email>ietf@nennemann.de</email>
|
||
</address>
|
||
</author>
|
||
|
||
<date year="2026" month="March" day="06"/>
|
||
|
||
<area>OPS</area>
|
||
<workgroup>NMOP</workgroup>
|
||
<keyword>federated learning</keyword> <keyword>agent privacy</keyword> <keyword>agent migration</keyword> <keyword>cross-protocol</keyword> <keyword>differential privacy</keyword>
|
||
|
||
<abstract>
|
||
|
||
|
||
<?line 43?>
|
||
|
||
<t>This document defines privacy-preserving protocols for federated
|
||
agent learning across organizational boundaries and standardized
|
||
mechanisms for agent migration between protocols, domains, and
|
||
infrastructure providers while maintaining state and identity
|
||
continuity. Federated learning enables multiple agent deployments
|
||
to collaboratively improve without sharing raw data, but requires
|
||
formal privacy guarantees to prevent data leakage between
|
||
participants. Cross-protocol migration enables agents to move
|
||
between environments while preserving operational state and
|
||
cryptographic identity through Execution Context Tokens (ECTs).</t>
|
||
|
||
|
||
|
||
</abstract>
|
||
|
||
|
||
|
||
</front>
|
||
|
||
<middle>
|
||
|
||
|
||
<?line 56?>
|
||
|
||
<section anchor="introduction"><name>Introduction</name>
|
||
|
||
<t>As AI agents become integral to enterprise workflows, two
|
||
capabilities emerge as critical yet underspecified: collaborative
|
||
learning across organizational boundaries and seamless migration
|
||
between protocol environments.</t>
|
||
|
||
<t>This document addresses Gap 5 (Federated Learning Privacy) and
|
||
Gap 8 (Cross-Protocol Migration) as identified in
|
||
<xref target="I-D.nennemann-agent-gap-analysis"/>.</t>
|
||
|
||
<t>Gap 5 concerns the absence of privacy-preserving protocols for
|
||
federated agent learning. As agents learn and improve through
|
||
federation, data leakage between participants must be prevented.
|
||
Current federated learning research provides theoretical
|
||
foundations, but no IETF-standard protocol exists that integrates
|
||
differential privacy, secure aggregation, and privacy budget
|
||
enforcement into agent communication frameworks.</t>
|
||
|
||
<t>Gap 8 concerns the lack of standardized mechanisms for agent
|
||
migration between protocols, domains, and infrastructure providers.
|
||
As agents need to move between environments -- whether for load
|
||
balancing, disaster recovery, or organizational restructuring --
|
||
state and identity must transfer safely. Without a migration
|
||
protocol, agents lose context, learned parameters, and
|
||
cryptographic identity when changing environments.</t>
|
||
|
||
<t>This document builds on the Execution Context Token (ECT)
|
||
framework <xref target="I-D.nennemann-wimse-ect"/> to provide cryptographic
|
||
audit trails for both federated learning rounds and migration
|
||
events, and on the Agent Context Policy Token
|
||
<xref target="I-D.nennemann-agent-dag-hitl-safety"/> to enforce privacy and
|
||
migration policies within delegation DAGs.</t>
|
||
|
||
</section>
|
||
<section anchor="terminology"><name>Terminology</name>
|
||
|
||
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
|
||
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
|
||
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
|
||
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
|
||
appear in all capitals, as shown here.</t>
|
||
|
||
<?line -18?>
|
||
|
||
<t>The following terms are used in this document:</t>
|
||
|
||
<dl>
|
||
<dt>Federated Learning:</dt>
|
||
<dd>
|
||
<t>A machine learning approach where multiple participants
|
||
collaboratively train a model without sharing raw data, instead
|
||
exchanging model updates (gradients or parameters).</t>
|
||
</dd>
|
||
<dt>Differential Privacy:</dt>
|
||
<dd>
|
||
<t>A mathematical framework providing formal guarantees that the
|
||
output of a computation does not reveal whether any individual
|
||
data point was included in the input, parameterized by epsilon
|
||
and delta.</t>
|
||
</dd>
|
||
<dt>Secure Aggregation:</dt>
|
||
<dd>
|
||
<t>A cryptographic protocol enabling a server to compute the sum
|
||
of participant updates without learning any individual update.</t>
|
||
</dd>
|
||
<dt>Privacy Budget:</dt>
|
||
<dd>
|
||
<t>A cumulative bound (epsilon) on the total privacy loss incurred
|
||
across multiple rounds of federated learning, enforced to prevent
|
||
gradual information leakage.</t>
|
||
</dd>
|
||
<dt>Data Leakage:</dt>
|
||
<dd>
|
||
<t>The unintended exposure of private training data through model
|
||
updates, inference attacks, or side channels during federated
|
||
learning.</t>
|
||
</dd>
|
||
<dt>Agent Migration:</dt>
|
||
<dd>
|
||
<t>The process of transferring an agent's operational state,
|
||
identity, and capabilities from one protocol environment, domain,
|
||
or infrastructure provider to another.</t>
|
||
</dd>
|
||
<dt>State Transfer:</dt>
|
||
<dd>
|
||
<t>The serialization, transmission, and deserialization of an
|
||
agent's internal state during migration, including context,
|
||
memory, learned parameters, and active tasks.</t>
|
||
</dd>
|
||
<dt>Identity Continuity:</dt>
|
||
<dd>
|
||
<t>The property that an agent's cryptographic identity (e.g., SPIFFE
|
||
ID and associated ECT chain) remains verifiable across migration
|
||
boundaries.</t>
|
||
</dd>
|
||
<dt>Protocol Bridge:</dt>
|
||
<dd>
|
||
<t>A component that translates agent communication between different
|
||
protocols (e.g., A2A to MCP), maintaining semantic equivalence
|
||
of messages and state.</t>
|
||
</dd>
|
||
<dt>Migration Handoff:</dt>
|
||
<dd>
|
||
<t>The coordinated process by which the source environment transfers
|
||
responsibility for an agent to the destination environment,
|
||
including state transfer and identity re-attestation.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="federated-agent-learning-privacy"><name>Federated Agent Learning Privacy</name>
|
||
|
||
<section anchor="federated-learning-architecture-for-agents"><name>Federated Learning Architecture for Agents</name>
|
||
|
||
<t>Federated learning for agents follows a topology where participant
|
||
agents contribute model updates to an aggregation function without
|
||
exposing their local training data.</t>
|
||
|
||
<figure title="Federated Learning Topologies for Agents" anchor="fig-federation-arch"><artwork><![CDATA[
|
||
+---------------------------------------------------+
|
||
| Federation Topology |
|
||
| |
|
||
| Star: Ring: Hierarchical: |
|
||
| |
|
||
| [Agg] A1--A2 [Root Agg] |
|
||
| / | \ | | / \ |
|
||
| A1 A2 A3 A3--A4 [Sub-Agg] [Sub-Agg] |
|
||
| / \ / \ |
|
||
| A1 A2 A3 A4 |
|
||
| |
|
||
+---------------------------------------------------+
|
||
|
||
[Agg] = Aggregation Server
|
||
A1..A4 = Participant Agents
|
||
|
||
Data flow (Star topology):
|
||
|
||
A1 ---local_update---> [Agg]
|
||
A2 ---local_update---> [Agg]
|
||
A3 ---local_update---> [Agg]
|
||
[Agg] computes aggregate
|
||
A1 <--global_model--- [Agg]
|
||
A2 <--global_model--- [Agg]
|
||
A3 <--global_model--- [Agg]
|
||
]]></artwork></figure>
|
||
|
||
<t>Three topologies are defined:</t>
|
||
|
||
<dl>
|
||
<dt>Star Topology:</dt>
|
||
<dd>
|
||
<t>A central aggregation server receives updates from all
|
||
participant agents and distributes the aggregated model. This
|
||
is the simplest topology but creates a single point of trust.</t>
|
||
</dd>
|
||
<dt>Ring Topology:</dt>
|
||
<dd>
|
||
<t>Participant agents pass updates around a ring, each adding its
|
||
own contribution before forwarding. This eliminates the central
|
||
server but increases latency.</t>
|
||
</dd>
|
||
<dt>Hierarchical Topology:</dt>
|
||
<dd>
|
||
<t>Sub-aggregation servers collect updates from subsets of agents
|
||
before forwarding to a root aggregator. This scales to large
|
||
federations while limiting exposure at each level.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
<t>The aggregation server (or function, in ring topology) <bcp14>MUST NOT</bcp14>
|
||
have access to individual agent updates in plaintext when secure
|
||
aggregation is enabled.</t>
|
||
|
||
</section>
|
||
<section anchor="privacy-mechanisms"><name>Privacy Mechanisms</name>
|
||
|
||
<section anchor="differential-privacy-for-model-updates"><name>Differential Privacy for Model Updates</name>
|
||
|
||
<t>Participant agents <bcp14>MUST</bcp14> apply differential privacy to model
|
||
updates before transmission. Each update is clipped to a maximum
|
||
L2 norm S and perturbed with calibrated Gaussian noise:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Clipping bound S: limits the influence of any single data point</t>
|
||
<t>Noise scale sigma: calibrated to achieve (epsilon, delta)-
|
||
differential privacy for each round</t>
|
||
<t>Composition: total privacy loss across T rounds is tracked using
|
||
the moments accountant or Renyi differential privacy</t>
|
||
</list></t>
|
||
|
||
<t>The privacy parameters <bcp14>MUST</bcp14> be declared in the federation
|
||
configuration and enforced by each participant agent.</t>
|
||
|
||
</section>
|
||
<section anchor="secure-aggregation-protocol"><name>Secure Aggregation Protocol</name>
|
||
|
||
<t>The aggregation server <bcp14>MUST</bcp14> implement a secure aggregation protocol
|
||
such that:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>Each participant agent secret-shares its update using pairwise
|
||
keys established with other participants.</t>
|
||
<t>The aggregation server collects masked updates from all
|
||
participants.</t>
|
||
<t>After a configurable threshold of participants have submitted
|
||
updates, the server reconstructs only the aggregate sum.</t>
|
||
<t>Individual updates are never available to the server in
|
||
plaintext.</t>
|
||
</list></t>
|
||
|
||
<t>Dropped participants are handled by reconstructing their masking
|
||
contributions from the shares held by surviving participants.</t>
|
||
|
||
</section>
|
||
<section anchor="privacy-budget-tracking-and-enforcement"><name>Privacy Budget Tracking and Enforcement</name>
|
||
|
||
<t>Each federation <bcp14>MUST</bcp14> maintain a privacy budget tracker that records
|
||
cumulative epsilon expenditure per participant. The tracker <bcp14>MUST</bcp14>:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Record the epsilon cost of each federated learning round</t>
|
||
<t>Refuse to include a participant whose cumulative epsilon would
|
||
exceed the configured maximum budget</t>
|
||
<t>Support budget refresh after a configurable cooldown period</t>
|
||
<t>Report remaining budget to participants upon request</t>
|
||
</list></t>
|
||
|
||
<t>Privacy budget state <bcp14>MUST</bcp14> be recorded in ECTs (see <xref target="ect-integration"/>)
|
||
to provide a cryptographic audit trail of privacy expenditure.</t>
|
||
|
||
</section>
|
||
<section anchor="gradient-compression-with-privacy-preservation"><name>Gradient Compression with Privacy Preservation</name>
|
||
|
||
<t>To reduce communication overhead, participants <bcp14>MAY</bcp14> compress model
|
||
updates using techniques such as top-k sparsification or random
|
||
sparsification. Compression <bcp14>MUST NOT</bcp14> reduce the effective privacy
|
||
guarantee below the declared epsilon -- noise <bcp14>MUST</bcp14> be added after
|
||
compression, calibrated to the compressed update's sensitivity.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="data-leakage-prevention"><name>Data Leakage Prevention</name>
|
||
|
||
<section anchor="membership-inference-attack-mitigation"><name>Membership Inference Attack Mitigation</name>
|
||
|
||
<t>Federation participants <bcp14>MUST</bcp14> apply differential privacy at
|
||
sufficient epsilon levels to bound the success rate of membership
|
||
inference attacks. The aggregation server <bcp14>SHOULD</bcp14> monitor update
|
||
distributions for anomalous patterns indicative of membership
|
||
inference attempts.</t>
|
||
|
||
</section>
|
||
<section anchor="model-inversion-attack-prevention"><name>Model Inversion Attack Prevention</name>
|
||
|
||
<t>To prevent reconstruction of training data from model updates:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Updates <bcp14>MUST</bcp14> be clipped and noised per the differential privacy
|
||
mechanism defined above.</t>
|
||
<t>The aggregation server <bcp14>MUST NOT</bcp14> release per-participant update
|
||
statistics.</t>
|
||
<t>Participants <bcp14>SHOULD</bcp14> limit the number of rounds in which they
|
||
participate with unchanged local data.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="update-poisoning-detection"><name>Update Poisoning Detection</name>
|
||
|
||
<t>The aggregation server <bcp14>MUST</bcp14> implement poisoning detection to
|
||
identify malicious updates that attempt to corrupt the global
|
||
model:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Statistical outlier detection on update norms and directions</t>
|
||
<t>Byzantine-robust aggregation (e.g., coordinate-wise median or
|
||
trimmed mean) as an alternative to simple averaging</t>
|
||
<t>Participants submitting suspected poisoned updates <bcp14>SHOULD</bcp14> be
|
||
flagged and excluded from subsequent rounds pending review</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="privacy-attestation-via-ect"><name>Privacy Attestation via ECT</name>
|
||
|
||
<t>Each federated learning round <bcp14>MUST</bcp14> produce an ECT
|
||
<xref target="I-D.nennemann-wimse-ect"/> attesting to the privacy mechanisms
|
||
applied. The ECT <spanx style="verb">ext</spanx> claim <bcp14>MUST</bcp14> include:</t>
|
||
|
||
<figure title="Privacy Attestation in ECT Extension Claims" anchor="fig-privacy-attestation"><sourcecode type="json"><![CDATA[
|
||
{
|
||
"ext": {
|
||
"fed.round_id": "round-42",
|
||
"fed.epsilon": 1.5,
|
||
"fed.delta": 1e-5,
|
||
"fed.participants": 12,
|
||
"fed.aggregation": "secure_aggregation",
|
||
"fed.poisoning_detected": false
|
||
}
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="privacy-policy-format"><name>Privacy Policy Format</name>
|
||
|
||
<t>Federation participants <bcp14>MUST</bcp14> publish a machine-readable privacy
|
||
policy document describing their federation parameters. The policy
|
||
is a JSON object:</t>
|
||
|
||
<figure title="Machine-Readable Privacy Policy" anchor="fig-privacy-policy"><sourcecode type="json"><![CDATA[
|
||
{
|
||
"federation_policy_version": "1.0",
|
||
"max_epsilon_per_round": 2.0,
|
||
"max_total_epsilon": 10.0,
|
||
"delta": 1e-5,
|
||
"secure_aggregation_required": true,
|
||
"min_participants": 3,
|
||
"budget_refresh_seconds": 86400,
|
||
"allowed_topologies": ["star", "hierarchical"],
|
||
"data_categories_excluded": ["PII", "PHI"]
|
||
}
|
||
]]></sourcecode></figure>
|
||
|
||
<t>Privacy level claims <bcp14>SHOULD</bcp14> be included in the ECT <spanx style="verb">ext</spanx> field
|
||
as <spanx style="verb">fed.policy_hash</spanx>, containing the SHA-256 hash of the
|
||
federation privacy policy document, enabling verifiers to confirm
|
||
that a specific policy was in effect during a learning round.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="cross-protocol-agent-migration"><name>Cross-Protocol Agent Migration</name>
|
||
|
||
<section anchor="migration-model"><name>Migration Model</name>
|
||
|
||
<figure title="Agent Migration Between Domains" anchor="fig-migration-model"><artwork><![CDATA[
|
||
+-----------------------------------------------------------+
|
||
| Migration Flow |
|
||
| |
|
||
| Source Domain (Protocol A) Dest Domain (Protocol B) |
|
||
| +---------------------+ +---------------------+ |
|
||
| | | | | |
|
||
| | [Agent] | | [Agent] | |
|
||
| | | | | ^ | |
|
||
| | | 1.trigger | | | | |
|
||
| | v | | 5.resume | |
|
||
| | [Serialize State] | | | | |
|
||
| | | | | [Deserialize State]| |
|
||
| | | 2.package | | ^ | | |
|
||
| | v | | |4.recv| | |
|
||
| | [Migration Msg]----|--3.transfer--|------+ | |
|
||
| | | | | |
|
||
| +---------------------+ +---------------------+ |
|
||
| |
|
||
| ECT Chain: migration_start -> migration_transfer |
|
||
| -> migration_complete |
|
||
+-----------------------------------------------------------+
|
||
]]></artwork></figure>
|
||
|
||
</section>
|
||
<section anchor="migration-protocol"><name>Migration Protocol</name>
|
||
|
||
<section anchor="migration-trigger-events-and-conditions"><name>Migration Trigger Events and Conditions</name>
|
||
|
||
<t>A migration <bcp14>MAY</bcp14> be triggered by any of the following events:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Operator-initiated domain transfer</t>
|
||
<t>Load balancing across infrastructure providers</t>
|
||
<t>Disaster recovery failover</t>
|
||
<t>Protocol deprecation requiring protocol change</t>
|
||
<t>Policy-driven relocation (e.g., data sovereignty requirements)</t>
|
||
</list></t>
|
||
|
||
<t>The migration trigger <bcp14>MUST</bcp14> be recorded in an ECT with
|
||
<spanx style="verb">exec_act</spanx> set to <spanx style="verb">"migration_start"</spanx>.</t>
|
||
|
||
</section>
|
||
<section anchor="pre-migration-capability-check"><name>Pre-Migration Capability Check</name>
|
||
|
||
<t>Before initiating migration, the source environment <bcp14>MUST</bcp14> verify
|
||
that the destination environment supports the agent's required
|
||
capabilities:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>Query the destination's capability advertisement endpoint.</t>
|
||
<t>Verify that all required agent capabilities can be mapped to
|
||
the destination protocol.</t>
|
||
<t>Verify that the destination accepts the agent's identity
|
||
format (e.g., SPIFFE ID).</t>
|
||
<t>Confirm sufficient resources at the destination for the
|
||
agent's state size.</t>
|
||
</list></t>
|
||
|
||
<t>If any check fails, the migration <bcp14>MUST</bcp14> be aborted and an error
|
||
reported to the triggering entity.</t>
|
||
|
||
</section>
|
||
<section anchor="state-serialization-format"><name>State Serialization Format</name>
|
||
|
||
<t>Agent state <bcp14>MUST</bcp14> be serialized using CBOR (Concise Binary Object
|
||
Representation) with the following top-level structure:</t>
|
||
|
||
<figure title="CBOR Migration State Structure" anchor="fig-state-format"><artwork><![CDATA[
|
||
migration_state = {
|
||
"version": uint, ; serialization format version
|
||
"agent_id": tstr, ; agent SPIFFE ID
|
||
"source_protocol": tstr, ; source protocol identifier
|
||
"dest_protocol": tstr, ; destination protocol identifier
|
||
"timestamp": uint, ; Unix timestamp of serialization
|
||
"state": {
|
||
"context": bstr, ; conversation/task context
|
||
"memory": bstr, ; long-term memory store
|
||
"learned_params": bstr, ; model parameters or embeddings
|
||
"active_tasks": [* task] ; in-progress task descriptors
|
||
},
|
||
"ect_chain": [* tstr], ; ECT JWS chain for identity
|
||
"integrity": tstr ; HMAC-SHA256 of state fields
|
||
}
|
||
]]></artwork></figure>
|
||
|
||
</section>
|
||
<section anchor="identity-transfer-and-re-attestation"><name>Identity Transfer and Re-Attestation</name>
|
||
|
||
<t>During migration, the agent's identity <bcp14>MUST</bcp14> be preserved through
|
||
the ECT chain:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>The source environment issues a migration ECT with the full
|
||
ECT chain as the <spanx style="verb">par</spanx> claim.</t>
|
||
<t>The destination environment verifies the ECT chain back to a
|
||
trusted root.</t>
|
||
<t>The destination environment issues a new ECT for the agent with
|
||
<spanx style="verb">exec_act</spanx> set to <spanx style="verb">"migration_complete"</spanx> and <spanx style="verb">par</spanx> referencing
|
||
the migration transfer ECT.</t>
|
||
<t>The agent's SPIFFE ID remains unchanged; only the issuing
|
||
authority for new ECTs changes.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="post-migration-verification"><name>Post-Migration Verification</name>
|
||
|
||
<t>After migration completes, the destination environment <bcp14>MUST</bcp14>:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>Verify state integrity using the HMAC in the migration payload.</t>
|
||
<t>Deserialize and load the agent state.</t>
|
||
<t>Execute a capability self-test to confirm operational readiness.</t>
|
||
<t>Issue the <spanx style="verb">"migration_complete"</spanx> ECT.</t>
|
||
<t>Notify the source environment of successful migration so it
|
||
can release resources.</t>
|
||
</list></t>
|
||
|
||
<t>If verification fails, the destination <bcp14>MUST</bcp14> notify the source
|
||
environment, which <bcp14>SHOULD</bcp14> retain the agent in its original state
|
||
for retry or rollback.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="state-transfer"><name>State Transfer</name>
|
||
|
||
<section anchor="agent-state-components"><name>Agent State Components</name>
|
||
|
||
<t>An agent's transferable state consists of four components:</t>
|
||
|
||
<dl>
|
||
<dt>Context:</dt>
|
||
<dd>
|
||
<t>The current conversation or task execution context, including
|
||
recent message history and active reasoning chains.</t>
|
||
</dd>
|
||
<dt>Memory:</dt>
|
||
<dd>
|
||
<t>Long-term memory stores such as retrieval-augmented generation
|
||
(RAG) indices, episodic memory, or key-value caches.</t>
|
||
</dd>
|
||
<dt>Learned Parameters:</dt>
|
||
<dd>
|
||
<t>Fine-tuned model weights, adapter layers, embeddings, or
|
||
reinforcement learning policies specific to the agent's role.</t>
|
||
</dd>
|
||
<dt>Active Tasks:</dt>
|
||
<dd>
|
||
<t>In-progress task descriptors including task ID, current step,
|
||
dependencies, and expected outputs.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="incremental-state-transfer-for-large-state"><name>Incremental State Transfer for Large State</name>
|
||
|
||
<t>For agents with state exceeding 10 MB, incremental transfer
|
||
<bcp14>MUST</bcp14> be supported:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>The source environment transmits a state manifest listing all
|
||
state chunks with their SHA-256 hashes.</t>
|
||
<t>The destination environment requests only chunks it does not
|
||
already possess (delta transfer).</t>
|
||
<t>Each chunk transfer is individually acknowledged.</t>
|
||
<t>After all chunks are received, the destination assembles the
|
||
complete state and verifies the root hash.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="state-integrity-verification"><name>State Integrity Verification</name>
|
||
|
||
<t>State integrity <bcp14>MUST</bcp14> be verified at each stage:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Before transmission: source computes HMAC-SHA256 over the
|
||
serialized state using a key derived from the migration ECT.</t>
|
||
<t>During transmission: TLS provides transport integrity.</t>
|
||
<t>After reception: destination recomputes and verifies the HMAC.</t>
|
||
<t>After deserialization: destination runs a state consistency
|
||
check (e.g., verifying that active task references resolve).</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="protocol-bridges"><name>Protocol Bridges</name>
|
||
|
||
<section anchor="bridge-architecture-for-common-protocols"><name>Bridge Architecture for Common Protocols</name>
|
||
|
||
<t>Protocol bridges translate agent communication between protocols
|
||
while preserving semantic equivalence. A bridge <bcp14>MUST</bcp14> support
|
||
bidirectional translation for each protocol pair it advertises.</t>
|
||
|
||
<figure title="Protocol Bridge Architecture" anchor="fig-bridge-arch"><artwork><![CDATA[
|
||
[Agent (A2A)] <--A2A--> [Bridge] <--MCP--> [Agent (MCP)]
|
||
|
|
||
[ECT Logger]
|
||
]]></artwork></figure>
|
||
|
||
<t>Each bridge instance <bcp14>MUST</bcp14>:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Maintain a mapping table for message types between protocols.</t>
|
||
<t>Preserve task identifiers across protocol boundaries.</t>
|
||
<t>Record each translation as an ECT with <spanx style="verb">exec_act</spanx> set to
|
||
<spanx style="verb">"bridge_translate"</spanx>.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="context-translation-rules"><name>Context Translation Rules</name>
|
||
|
||
<t>When translating context between protocols, bridges <bcp14>MUST</bcp14>:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Map equivalent fields (e.g., A2A "task" to MCP "resource").</t>
|
||
<t>Preserve all metadata as extension fields where direct mapping
|
||
is not available.</t>
|
||
<t>Flag semantic mismatches in the translation ECT's <spanx style="verb">ext</spanx> claim
|
||
under <spanx style="verb">bridge.warnings</spanx>.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="capability-re-mapping"><name>Capability Re-Mapping</name>
|
||
|
||
<t>Agent capabilities expressed in the source protocol <bcp14>MUST</bcp14> be
|
||
re-mapped to the closest equivalent in the destination protocol.
|
||
Capabilities with no equivalent <bcp14>MUST</bcp14> be listed in the migration
|
||
state as <spanx style="verb">unmapped_capabilities</spanx> so the destination environment
|
||
can handle them appropriately (e.g., by loading additional
|
||
tooling or reporting reduced functionality).</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="privacy-during-migration"><name>Privacy During Migration</name>
|
||
|
||
<section anchor="context-sanitization-before-transfer"><name>Context Sanitization Before Transfer</name>
|
||
|
||
<t>Before state serialization, the source environment <bcp14>MUST</bcp14> sanitize
|
||
the agent's context by:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Removing credentials, API keys, and session tokens.</t>
|
||
<t>Redacting PII unless the destination is authorized to receive
|
||
it per the agent's privacy policy.</t>
|
||
<t>Stripping environment-specific configuration (e.g., internal
|
||
hostnames, file paths).</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="selective-state-disclosure"><name>Selective State Disclosure</name>
|
||
|
||
<t>The migration protocol supports selective state disclosure:
|
||
the source environment <bcp14>MAY</bcp14> omit state components that the
|
||
destination is not authorized to receive. The migration state
|
||
manifest indicates which components are included and which are
|
||
withheld, allowing the destination to request missing components
|
||
through an authorized channel if needed.</t>
|
||
|
||
</section>
|
||
<section anchor="no-context-leakage-guarantees-to-new-host"><name>No-Context-Leakage Guarantees to New Host</name>
|
||
|
||
<t>The destination environment <bcp14>MUST NOT</bcp14> have access to state
|
||
components that were excluded during selective disclosure. The
|
||
migration protocol provides the following guarantees:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>State components are individually encrypted with component-
|
||
specific keys.</t>
|
||
<t>Only authorized components have their keys transmitted to the
|
||
destination.</t>
|
||
<t>The destination cannot derive keys for withheld components
|
||
from the keys it receives.</t>
|
||
<t>The migration ECT records which components were transferred,
|
||
enabling audit of information flow.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
</section>
|
||
<section anchor="ect-integration"><name>ECT Integration</name>
|
||
|
||
<section anchor="privacy-attestation-claims"><name>Privacy Attestation Claims</name>
|
||
|
||
<t>ECTs produced during federated learning rounds <bcp14>MUST</bcp14> include
|
||
privacy attestation claims in the <spanx style="verb">ext</spanx> field as defined in
|
||
<xref target="privacy-attestation-via-ect"/>. These claims enable any
|
||
verifier in the ECT chain to confirm that appropriate privacy
|
||
mechanisms were applied without accessing the underlying data.</t>
|
||
|
||
</section>
|
||
<section anchor="migration-evidence-chain"><name>Migration Evidence Chain</name>
|
||
|
||
<t>Migration events produce a chain of three ECTs that together
|
||
provide a complete cryptographic record of the migration:</t>
|
||
|
||
<figure title="Migration ECT Evidence Chain" anchor="fig-migration-ect-chain"><artwork><![CDATA[
|
||
ECT 1: exec_act = "migration_start"
|
||
- Records: trigger reason, source domain, agent ID
|
||
- par: references the agent's most recent operational ECT
|
||
|
||
ECT 2: exec_act = "migration_transfer"
|
||
- Records: state hash, components transferred, dest domain
|
||
- par: references ECT 1
|
||
- inp_hash: SHA-256 of serialized migration state
|
||
|
||
ECT 3: exec_act = "migration_complete"
|
||
- Records: verification result, new domain, resumed capabilities
|
||
- par: references ECT 2
|
||
- Issued by: destination environment
|
||
]]></artwork></figure>
|
||
|
||
<t>This three-ECT chain ensures that migration events are
|
||
non-repudiable and auditable. Any party with access to the
|
||
ECT chain can verify that a migration occurred, what state was
|
||
transferred, and whether it completed successfully.</t>
|
||
|
||
</section>
|
||
<section anchor="federation-participation-records"><name>Federation Participation Records</name>
|
||
|
||
<t>Each agent's participation in federated learning <bcp14>MUST</bcp14> be
|
||
recorded in the ECT DAG. The aggregation server issues a
|
||
per-round ECT with <spanx style="verb">exec_act</spanx> set to <spanx style="verb">"fed_aggregate"</spanx> and
|
||
<spanx style="verb">par</spanx> referencing the ECTs of all participating agents for
|
||
that round. This creates a verifiable record of federation
|
||
participation without revealing the content of individual
|
||
updates.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="security-considerations"><name>Security Considerations</name>
|
||
|
||
<section anchor="privacy-budget-exhaustion-attacks"><name>Privacy Budget Exhaustion Attacks</name>
|
||
|
||
<t>An attacker controlling the aggregation server or a quorum of
|
||
participants could attempt to exhaust a victim participant's
|
||
privacy budget by triggering excessive learning rounds.
|
||
Mitigations include:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Participant-side rate limiting on round participation.</t>
|
||
<t>Privacy budget enforcement at the participant, not solely
|
||
at the aggregation server.</t>
|
||
<t>ECT-based audit trails enabling detection of abnormal round
|
||
frequency.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="migration-hijacking"><name>Migration Hijacking</name>
|
||
|
||
<t>An attacker could attempt to redirect a migration to a
|
||
malicious destination. Mitigations include:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Mutual TLS authentication between source and destination.</t>
|
||
<t>Destination identity verification via SPIFFE ID in the
|
||
migration ECT.</t>
|
||
<t>Operator confirmation for migrations to previously unknown
|
||
destinations.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="state-tampering-during-transfer"><name>State Tampering During Transfer</name>
|
||
|
||
<t>An attacker with access to the network path could attempt to
|
||
modify the migration state in transit. Mitigations include:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>HMAC-SHA256 integrity protection of the serialized state.</t>
|
||
<t>TLS 1.3 for transport security.</t>
|
||
<t>Post-migration state verification at the destination.</t>
|
||
<t>ECT <spanx style="verb">inp_hash</spanx> recording the expected state hash.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="protocol-bridge-vulnerabilities"><name>Protocol Bridge Vulnerabilities</name>
|
||
|
||
<t>Protocol bridges are trusted intermediaries that could be
|
||
compromised to:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Modify messages during translation.</t>
|
||
<t>Exfiltrate sensitive data from translated messages.</t>
|
||
<t>Inject malicious content into translated messages.</t>
|
||
</list></t>
|
||
|
||
<t>Mitigations include:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>ECT audit trails for all bridge translations.</t>
|
||
<t>Input/output hash verification via <spanx style="verb">inp_hash</spanx>/<spanx style="verb">out_hash</spanx>.</t>
|
||
<t>Bridge attestation using hardware security modules where
|
||
available.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="federation-participant-compromise"><name>Federation Participant Compromise</name>
|
||
|
||
<t>A compromised participant could attempt to:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Submit poisoned updates to corrupt the global model.</t>
|
||
<t>Conduct inference attacks on other participants' updates
|
||
observed during ring topology forwarding.</t>
|
||
<t>Collude with the aggregation server to bypass secure
|
||
aggregation.</t>
|
||
</list></t>
|
||
|
||
<t>Mitigations include:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Byzantine-robust aggregation algorithms.</t>
|
||
<t>Secure aggregation preventing server access to individual
|
||
updates.</t>
|
||
<t>Anomaly detection on update distributions.</t>
|
||
<t>ECT-based participation records enabling forensic analysis.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="iana-considerations"><name>IANA Considerations</name>
|
||
|
||
<t>This document requests the following IANA registrations:</t>
|
||
|
||
<section anchor="ect-action-type-registry"><name>ECT Action Type Registry</name>
|
||
|
||
<t>Registration of the following <spanx style="verb">exec_act</spanx> values in a future ECT
|
||
action type registry:</t>
|
||
|
||
<texttable>
|
||
<ttcol align='left'>Value</ttcol>
|
||
<ttcol align='left'>Description</ttcol>
|
||
<c>migration_start</c>
|
||
<c>Agent migration initiated</c>
|
||
<c>migration_transfer</c>
|
||
<c>Agent state transferred</c>
|
||
<c>migration_complete</c>
|
||
<c>Agent migration completed</c>
|
||
<c>fed_aggregate</c>
|
||
<c>Federated learning round aggregated</c>
|
||
<c>bridge_translate</c>
|
||
<c>Protocol bridge translation</c>
|
||
</texttable>
|
||
|
||
</section>
|
||
<section anchor="ect-extension-claims-registry"><name>ECT Extension Claims Registry</name>
|
||
|
||
<t>Registration of the following <spanx style="verb">ext</spanx> claim prefixes:</t>
|
||
|
||
<texttable>
|
||
<ttcol align='left'>Prefix</ttcol>
|
||
<ttcol align='left'>Description</ttcol>
|
||
<c>fed.</c>
|
||
<c>Federated learning privacy claims</c>
|
||
<c>mig.</c>
|
||
<c>Migration-related claims</c>
|
||
<c>bridge.</c>
|
||
<c>Protocol bridge claims</c>
|
||
</texttable>
|
||
|
||
</section>
|
||
<section anchor="media-type-registration"><name>Media Type Registration</name>
|
||
|
||
<t>Registration of the following media type:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Type name: application</t>
|
||
<t>Subtype name: agent-migration-state+cbor</t>
|
||
<t>Required parameters: none</t>
|
||
<t>Optional parameters: version</t>
|
||
<t>Encoding: binary (CBOR)</t>
|
||
<t>Purpose: Serialized agent migration state for cross-protocol
|
||
agent migration as defined in this document.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
|
||
|
||
</middle>
|
||
|
||
<back>
|
||
|
||
|
||
<references title='References' anchor="sec-combined-references">
|
||
|
||
<references title='Normative References' anchor="sec-normative-references">
|
||
|
||
|
||
|
||
<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="RFC7519">
|
||
<front>
|
||
<title>JSON Web Token (JWT)</title>
|
||
<author fullname="M. Jones" initials="M." surname="Jones"/>
|
||
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
|
||
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
|
||
<date month="May" year="2015"/>
|
||
<abstract>
|
||
<t>JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted.</t>
|
||
</abstract>
|
||
</front>
|
||
<seriesInfo name="RFC" value="7519"/>
|
||
<seriesInfo name="DOI" value="10.17487/RFC7519"/>
|
||
</reference>
|
||
<reference anchor="RFC7515">
|
||
<front>
|
||
<title>JSON Web Signature (JWS)</title>
|
||
<author fullname="M. Jones" initials="M." surname="Jones"/>
|
||
<author fullname="J. Bradley" initials="J." surname="Bradley"/>
|
||
<author fullname="N. Sakimura" initials="N." surname="Sakimura"/>
|
||
<date month="May" year="2015"/>
|
||
<abstract>
|
||
<t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
|
||
</abstract>
|
||
</front>
|
||
<seriesInfo name="RFC" value="7515"/>
|
||
<seriesInfo name="DOI" value="10.17487/RFC7515"/>
|
||
</reference>
|
||
<reference anchor="RFC9110">
|
||
<front>
|
||
<title>HTTP Semantics</title>
|
||
<author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
|
||
<author fullname="M. Nottingham" initials="M." role="editor" surname="Nottingham"/>
|
||
<author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
|
||
<date month="June" year="2022"/>
|
||
<abstract>
|
||
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.</t>
|
||
<t>This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.</t>
|
||
</abstract>
|
||
</front>
|
||
<seriesInfo name="STD" value="97"/>
|
||
<seriesInfo name="RFC" value="9110"/>
|
||
<seriesInfo name="DOI" value="10.17487/RFC9110"/>
|
||
</reference>
|
||
|
||
<reference anchor="I-D.nennemann-wimse-ect" target="https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/">
|
||
<front>
|
||
<title>Execution Context Tokens for Distributed Agentic Workflows</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
<reference anchor="I-D.nennemann-agent-dag-hitl-safety" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/">
|
||
<front>
|
||
<title>Agent Context Policy Token: DAG Delegation with Human Override</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
|
||
|
||
</references>
|
||
|
||
<references title='Informative References' anchor="sec-informative-references">
|
||
|
||
<reference anchor="I-D.nennemann-agent-gap-analysis" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/">
|
||
<front>
|
||
<title>Gap Analysis of IETF Agent-Related Drafts</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
|
||
|
||
</references>
|
||
|
||
</references>
|
||
|
||
|
||
<?line 754?>
|
||
|
||
<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>
|
||
|
||
<t>This document builds on the Execution Context Token specification
|
||
<xref target="I-D.nennemann-wimse-ect"/> and the Agent Context Policy Token
|
||
<xref target="I-D.nennemann-agent-dag-hitl-safety"/>. The gap analysis
|
||
<xref target="I-D.nennemann-agent-gap-analysis"/> identified the requirements
|
||
addressed by this document.</t>
|
||
|
||
</section>
|
||
|
||
|
||
</back>
|
||
|
||
<!-- ##markdown-source:
|
||
H4sIAAAAAAAAA6V97XYbN5L2f1xFvfSPWDtsOrKdnSwzmX1pyY61x7K1kjJz
|
||
5mS9MtgNkhg3Gz0AmjJje65lr2WvbE9VAWg0Scn50I9E6m58FQr1+RRcFIXw
|
||
2tdqCqMXqlJWelXBbKkaD6+UtI1ulnBh9UaWW5BNBSfWOFdcWONNaWo410sr
|
||
vTbNSMj53KrNFEbcOvSmTRPbj0QpvVoau52C85WoTNnItZpCZeXCF41qGrWW
|
||
TVNI7KBYpA6Kljsovv5auG6+1s5p0/htq6Zw9vz6hWi69VzZqaikV1OxmcIT
|
||
Ia2SUxi9ubgaiVtj3y+t6dopjF6fv7kYifdqe2tsNRUABSzSuuuwYnpMs4Aw
|
||
dPZkHZdMz0qiRxvoQY8qvVgoqxqvZZ3aC9n5lbE0ogAAWHR1zcs/WVntvJYN
|
||
vI4koC+MXcpG/0xjTeGsqVSrmgqncKmckrZcKUsfqrXU9RS08ov/n6g4qZQQ
|
||
jbFr6fVG4biXL04eHx//W/j12+M/Pg2//vGb9PSP3xx/E379t+Pjr/HXs+J0
|
||
0u/NrV47VajST2noyDvPP6iyo80+MY1XHzxcm/eqcbAwFk6181bPu8RauoS/
|
||
Gvt+UZtbN+J+pF0qP4WV962bPnpUSS+9leV7ZSe4romxy0eVKR/t8kqaz6O9
|
||
qTIbVXJZrLSvCycXym+H02ZWjVO+MLUutzzzKZzOfoBTVaslM/Gt9it42a1l
|
||
A282ylpdqd859YPzeySEbhb5th1a1FK2hWxkvXXaDVf0g2xhFt6AWdD5YKIX
|
||
l6omLj/Fefxeuu/P45EQRVGAnDvswAtxvdIOKlN2ayRypRa6US4eiKK1yim7
|
||
QfkSTw9zSzqOgs9bPJQg6awNjoWsYW66ppJWK0fyyXmJf1b6Z1WJtSpXstFu
|
||
zT3vnF+YK3+rVNOPP4bKrKVu3Bj7wo2w0nnblb6zCj/b6EpZB7crXSvAL73U
|
||
NDfnpVc0AY0nVPutKE3jddNpv50AvNiTMaAaOa+Vg3VXe93WKkyvUm1ttkgy
|
||
J7yB0tS1nBtL7FBvQa9xGorY0XQe3Epa7M3KW8DNG8O882DVPzptlRPESUkK
|
||
wbKTVjZeKQfeQGvVhoaUXuK83sulikQRrbRel7qVjXcTCHI/UiojYlwGzZ66
|
||
XZuNEpG2qtloaxpaT6BbtvOmDSJe1j0JRWm3rTdLK9uVLhNBwa+s6ZYruFPW
|
||
PHx+cu2OJsyHa11VtRLiAZw13pqqK0lmi5mD2Vmc7VyVZq1AN14traxx9qrx
|
||
yrZWOwW3UUaNwd8aUcpWznWtPfKaWiu7VCAdlFZ7XcoatspD1yCDtKrUC62q
|
||
6XD7xK9kZSXXtXIu0zi7HDsg72T3yMmqsso55QClwjfwsOfCXd1+RITHz76F
|
||
h3fp+CNcLm8Hrg50Iz5+/JJ4+vx5IgSPX5qmVLZx4FcK5YRqSoUy6ksiQfQa
|
||
eigSJgCzxHn0kI9gOCOBYURvSYwP8jrkvA7rznmYq3g6VDURJ51FfX7AUgAb
|
||
VHGUDrQ4YxWxhFjQjuLIjg9mY0giF1FMZTv5QTs8PyvpIz965cQhY2IMTpUo
|
||
keRyaYN+IomVzvm8q5bKC4WapFTEDLrxJpCvNOt11+iSD/DCyrVCVndho74d
|
||
blQty/e4S7lkhUOSVfxiyQp3SdaJ6PezUaqK4gQOipOigNuV8itlaRK1kZWY
|
||
y1o2pW6WY6i0k84rC1aVZqPsdgzG7p45q+I0cDeLQuxLcuYIb2XjFsoC6uka
|
||
ZfpfgwiW2QGNCx4nrjROIT1RTo2ZbVSFDCfXyisbNM0dEu92pRpAQi9ZYdxz
|
||
1uedrisHpqE9u0NEkoQ8EmnHYff4Jmvq82dWELQvMJiekF2liR46aOy58auD
|
||
ZwO5n2VZTyE6VIENwmzvtsLukC87NhNPNjB7OgNI154jW+wVJSsqTt1A1Vt2
|
||
p7MfkJ4P4FrZtW5MbZZbJK+C92qLSqByMDr/8ep6NOb/w+s39Pvl8//88ezy
|
||
+Sn+fvVy9upV+kWEL65evvnx1Wn/W9/y5M35+fPXp9z49ZtrGDwSo/PZ30ZM
|
||
pNGbi+uzN69nr0agkV4DCW8VLn3OKsy2VpGQdKJSrrR6TkIanp1c/O//HD+F
|
||
jx//X/ABPn8Of6AX8PkzMVrcknob/vQrtRWybZW02Iusayhlq73E4ywduJW5
|
||
bWClrJoI8S8/IWXeTuFP87I9fvrn8AAXPHgYaTZ4SDTbf7LXmIl44NGBYRI1
|
||
B893KD2c7+xvg78j3bOHf/r3WjcKiuNv//3PgnlkYera3CK7e2XXjrakc0z4
|
||
wWZNhdjXv1MxhRmsZbnCfnv7oG2tkeUKd8Kq3kTMFZWAPeMQz2SD8shUqr7H
|
||
RNSN80pWAkB9SOKFG3UtOtEOHi6trDSJMGMzeYXm1Wmuk4IBERfiVwpdF7SH
|
||
ejHDcgQHCfZoboeiwvMrJQBM59vOo66RqKPazvMBrYxy0Bg0azdK1knoy2YL
|
||
uqn0RledRN+blHtrdOPhFk2Vpqy7Km4FnpG28+N+MaTJ5ltQrdM1+fN4AipV
|
||
ezkR4op17KzXsbzGoazOLDE5r2nvAI0YZYGsd1yFotFdt8Y1LvJNTOSOe9Vz
|
||
wGBt4buJEDEW84w0fJhRt+5q4gE2IeFhWNFRlLDe+MwLqNH21E2JVg0yQbBG
|
||
E5cFuW0WB4T6OMrZKvMgBACyC040Oa+miWYWcgxuzCv+E+eMB6drUGY1uD/q
|
||
Q2scEjsag0gyG1wr2tRo+xOTCoh0Q1YmViwVSO9l+d6RknektVayaVTtoGLl
|
||
3juW0FuQQrD2SUZunF5rTYnGt1kk1W95Y1i1f+X2vZexgKS8WZwOfIaFNWsw
|
||
jTpovkcLCfsw9i4LCYkuG4PsjyxKtsp1mF6cuVNWyzqYOGOefYiZjQOHDz6h
|
||
A0fcH9ZFuqR3yQL5ki4dh4OFD6NlIwDWam3QxrrDxgFZEod66cjSPItGzkny
|
||
kzPSt8qSxyd9TvA7zKSHarKcjOHq4uzFi+cYMTnlAZ0zpSbufX5yjeygmyOw
|
||
iuxQ2CirFxp918T/WWCvd8XozIXtemZ1xQw8o6NtGmQdlmBI5ZrO8iEjO9qv
|
||
yZwXkPk4YQGzxzPc3/OTi6PxMLqAxg9GzdCt38ga+Z1lyVo5J5d97INkROJl
|
||
eCmbyiwWkbClMbbSDZEk8vcc1b0uVyyjTIcmVMaWiflR31jlWtM4TRy9Zcs/
|
||
7A5OHHuolPM4AocGeu7Gk5G4hvkqWdQDY9uqQnqvHMt+ssu+FJgW4kH+UXo9
|
||
s+VKe8UnCCdLzV2uh5O8TV6MCxrdgQRvWrIGgxrOBLcI3yL/c2hzR3/SOc0d
|
||
NFh0TZkiiabzgqQeGQ4rpdF9QaU5EHsTIf75z3+KPxS//ucP4hMMfrJ4/HVc
|
||
1v7Pp91mv+yHm115aafx0SVaN/GPl1pZ9JLRLpjuNvuNowHAT7Pl8i3/Ojsu
|
||
itnj8MFPl8Z46F8Omz2CT/Bf8Vn6D70IP/+132x2DID9z57gH0+KYvaURrrq
|
||
5gUPlP36xaU9ygbJf7+3GU6BJxGmATyH30PI38ZaIpL++9w8giuyewTOdDKZ
|
||
PYXv4SIzdeLhAyBrAANr8BBZJh2zo6mgxlAUBZ2GGz5NRVH8mQcUtP57Xz+5
|
||
9zX/8OSDcebSKVU8+p+KYlmbuaxv6EhjMDEb/L63T+5+i+f44xQeLPQyz2xR
|
||
6Ihi99+PDkiwcFLJeEjya/QZPQ+rVCQcBQytCiH2akqGgU3HPOgr1XgMceYi
|
||
KRiqVpVKb5RLwosMFVmjoZUbq0HmkQmRUjohmhdJWLEcnABgfAKlPn/g9Lqt
|
||
FcZRovDBcFhpFatMQEGIDg4Z72Rzdc5PhLjMyEArudifUCtdP3dJ1itIsGyt
|
||
ohclK1I7mpwmdFqT2GbdvDCsIG4xvEVhRQquqFqvSVvyEgIFBUS64Qp0g2vA
|
||
GCsq/6bcToTIpd1g7igh9unvyI9TpR/S33VzpzwZoLxONEt2p0p6BiyKu9ix
|
||
sXH+rpQ1q6Ia0zwCoOe8GIzHJXqKLkUbXHomWq02qp6wk3uAaR5iqiaoNLQI
|
||
id79UYbo/YuV3KCJRcaGN7lTw4ZDXLRuoK3R6MEgEEW+OMop8sFxVyjhUE1I
|
||
60d36DzFI/HxAzjkotIROict/SOPKcQBbqKJy7attwczuRySRC8kTjxsSm5n
|
||
TwCeIw35E5x1Weu2ZadJwlp+0OtuLV49BszQwhUHb5X1ncWYDeUaS1nrOcuD
|
||
H2TnHCaIG6OdmgpRwAn2hxRnj+9qyjvpgqO7qLsYXUdPMpyu3j8WBbzGvphH
|
||
wOnlWk7zIXGe5UqrjUre5Jhd4yPMXx+kDNKXWIeOIE4SbWSnOYF9wAcNhvd1
|
||
9DhRVlDysYLOcR4el7M2HO+VZWm6xuNeGQuXqtnqO5Lt7EXwSL0fwls7R0FZ
|
||
1tL2gYH+WGDWbqGXXbCUcFuSv4uRAlzdnkicMM/tBwwgeg53niKaEYlGjucd
|
||
iOwnP0G4jsx0iaGk4wlz2N5ksAerfIFRHzxVPopGJim0Uttb7VAaYHzTAZra
|
||
81q7VWQ88i4HoaaJeDyBO1YQZJeDtXS0cfs6ZKevJxOYLTAuj1GeQG10w/zK
|
||
KrcydbUTJHFAIoSQH57d997/9+zwBjVmGnaZHccxB5oJAzAT8XSCSIphWIW1
|
||
Z6OwE7mRuubpmLxzTZiMJKAwpmENnejBTLGjlWyqmvklm1Jv6COhkLlzJRTo
|
||
RQPyxq1UTV24zm4058QGVCSWG0aDMBJQvucgRQXP++SPEMQrPZsz30UXE+RO
|
||
4iicQsuuLS7CVk5kYaYgEVBpqKbSHKIYMg0pIZV6wgFJcF1Sb7TS2EtpHOl8
|
||
lU1yL49ATRedU6xEKLKHE8/4/3ZFyZb9ad6arg7RTkoqkSvMnIcGC0vjmDQr
|
||
4KprW2N9JIZVC2RMkIeYtjSmrtCkaJXVhmdJjTnOQBI60NQMWaVrTUOJeuV8
|
||
H9cLH7OHHOUV7wDLK8xxw0OnFHz8qEpfxFyhNs3nz0ciy9rInXhJlrfJsq75
|
||
Hgau+iGEfkl+YwY54V/iLC84U8siU1wbsKrqSrUT9MCk20rJajxc+Pnsb2R7
|
||
W8ptD1QpiyivylWjkTBAIk+i4dAW78G10jq9SP1bsBjgWIvhC4QrZDOPlkic
|
||
JLHeYqE4HhV1RgpJw1yha8LBjKAnIiMVBavgtDOywm0hzhBlP+Z4R5Uyx/Hr
|
||
JCO/cuBUg+pxgyARsmfyQClSGaOrRGPcl3OFMDe30i2cpbDnjMKecK69Xob9
|
||
yFz9IeG/YNlIL1y3WGCerPFpzWQHkunGpgbHstmewwVyGCrOTOwFZIMgOKA6
|
||
Qu5mbRrtjQ1UEcm1YLFIMSazlrXp0NL3nhLTaEWWfMjvGV6t2yQq2fA7a9Dg
|
||
xjkEuuU0vu4hMbng5gjpMB5N0noQ8SHhFuzKxB7R6kN5TIxDVh7z1iHDBfrE
|
||
evTmQM7NRk1EcRcVM/au0RPBEYr9HAO6LRhTc16XDru7yFkjbAXZkDQ9hlTi
|
||
wqNt1vRxwm3uGHoGI0HXUCoJBTdFskIAC2nPZIELo50hGp4qDMsx0X+RYdSm
|
||
plVsCt6IAEbZwlpiehdZJAXgKHbMPMCpGGu7lhfHLrqg/aN9u4qUkTVmoWqt
|
||
bDaQaaIJhdZ6dIAtv3WigGfbnzE+26jCmjmCBfIFheBuH3st0PyCtarQojcY
|
||
L/FWr9eEqpAMssHQYU1BeI6Zm+A/g9woKzFdt7uBwTqi6GqHACSK8RLVMqMs
|
||
bPOcfMFaLpeBN9WHkCnrPc9/dHQOePNJQxDaZaPV7dD2mPXRWthoiQpqaG/s
|
||
qXLe3JZAWQi1oCb3QRE4IBzcXZ/Z9j0MBRPVtVZVkDYY8H+nPvh3UNZSrwM7
|
||
sdUwpajq351pxEcBMFIf/GgKHyk6NFqoakKTvNHVaAoj+r14+ng07t8HyTia
|
||
wvHkm+w5uUf4VBX541wG49vH2buMUXA0tv5v8qd5R/EQ3DBvKpzhQtZkzH8W
|
||
nwdBpgiqyoLpMdB0aOfYsoDnHzyqJASOIN0o1pTtdcBmvKAU3xcUTduRV0Hu
|
||
LqW3C6tkRUZTFHctd5dhRAm10JvKi8EAwY0LW8yNhcbo0X9cvXkNZv53wiUP
|
||
d7fv4oZb3AQNgPQ+nnxNBB6t5YebsK03rbI3tO2jKTyefJ3ekwN7k23+1+Hl
|
||
7r4f2MabgMjEPr3tFHeqm5sd5nhCL9gIvAmG541DZVTh62//9enXPKbEHIWq
|
||
bvoQ4GgKP42clxYRJassBDV6y7OUXt4EBL5W7iaeeWp3cXaGzS5eno3e3sFI
|
||
YbMCD52HPb2MezpkEeSb+IQMCD6HmQTay873R3ahVV0J6eAdcz3t2kq61bsx
|
||
Re6CIsZGVy9nxeNv/hXwLWnplRI508QYwJDRxn22ntOAGBwgHdEstF0L1h0Q
|
||
cJxlbM6YgmA7xrSo3BFulLHaQVDupJjpSPVJOrJMfnum586MD/30w7xAq/ae
|
||
VMBvyiDkra84eXhKaWx42K/+CD85xeDv3rtnR7H14aX/gfu/5yU1Pjz3T4P/
|
||
HXoZG/9EO/T2S43TZ4PGB0Y4PPJ/HxgZ/3M88VYvl8re1/jTwcabL478zcQq
|
||
163V/pqvAghAkfmj3v66ke9Z80+nCWAQ+95r/HjSypK8nEPT/u/9p798zZ+e
|
||
TqwqN4ca/5SdOrd8i0z0qSieTGIqmv7M+G5n5L2fX8hhv4u3f/MPtUapeoLI
|
||
h2mPb7hBLeGh+HP2KCXjB63v+Rm0Rt+2Vl5lrX+fKMsVUBqmYIcraKAdoQrP
|
||
AsSCZUy0XPr3fSz2weD5dTh7zzcpu3ViMCBCxr2YZbUOGLmYY0yLWnCID8Pr
|
||
rHgyKCCDXMm1eEMgIWML3WjPaBQG+iT8gyjglZEVJOhyjIvfhZIWBZZUDbHN
|
||
sJC6xt/QMYjStVKtVSFYwgZIjq1nZLHCBqTfisrqjcIv0YHLfRdyeR32rvSy
|
||
IZAGWTMUlj9iH66nUhRmh6JXbOyTwyjeqQ+qvJGlfweO42PvRjs8OnqXAp2q
|
||
6LfsJKKqtnCyUuV7IZ5xDibQeAeudAeyheZH+n8rIgrxLvwKOI4Jxmwn45Gi
|
||
UTcoDeHg/H92uCk7PSKEqZ+6rDbKeu3Yw1VNRZkZirX/hWYVfNi6TgNFbFGO
|
||
KislpjBhLUN+Cf2F3ZXELafge9757oeYp2t3VpkqmrBqkSz/IeIKzk6PKLB+
|
||
wuYTZEEkq5jwDg4MhrEdRn6msTju6fTPGIs84+RViVtM/B3i/dmBjGG4ubE+
|
||
+LKyAWWtscJSILYPwAW+ZCi9jyG3B6yh4GoAiYseDguZYTQ26baQpYKTZ28u
|
||
4eGJaUp07J/pRtotvCFvRFwqqmppfKigoVDJUFhgbJNt5HTW2YkRg9PgFXxP
|
||
Xuqod2A6jcZs9vPdEP0X9yu0IMcBV8TOrXfejgeNmb3StpIvQ/t3Ezkob/Zd
|
||
PFVJoqTiIMt+kfMHG2LTQ+y5097rNfqn63Z/pd/Bj43+AOkLKlDJV05TR6L1
|
||
rn3AKo6mMB8u/Ds0/JFE1PIRIhQjsJFbMrRxvyF8B7VplgUivwP+EZw3VnGz
|
||
gIS8IdfVZc2/C6HDLDWJqdP1XBFQwXFzBkzeEGASnbR/IezkW2yusSbaLCmC
|
||
TtNlz7n1hnB6n8nhU6W/IdBjaOy8fZvIj1L4P/56xahIOonZMR9xUkH7bdi1
|
||
IYu9PJ+dFFcvZ+h4cWGQV+y0uR3fkV4VgQmD3qbT0svycPoi57PafgAJHnqd
|
||
owQvVZEFLYQ43YOmHhJc6eSGAjNKAXFpWHQ8iQwsua8PawvtXEdIlV76RE3G
|
||
57njXGfqjdIWKwXvWmlDGCrlUe/SMsEbdTCYF8wxUo0ZeZLtiIxRFYE+SJ7f
|
||
12GadaNuqcMgc8NJJz0MAPer4mjdjd7RJvCCrOJAO6fpd+Rysiafn1yTarjO
|
||
tiWJl4TFTaHj7/q8Lc489M2l8xFxGlbigvmSUqHG+cxEICUX8kFCcL65n19c
|
||
UVAod1EvJC2Pk85kVk+nI+arVorORIxkZFVHcotVabTvuVOEZMQX2VYE8O6T
|
||
SSjeovxdbyw4VS8KzwCqGKcYANAxuIYF1o5z3LjvzH6HN5I25psJvDaejYGD
|
||
TI+nm1M9iy4v+nUGNMlGND5i3iHpelbdm2wHcu2dE5sOZrM7BTGAxXPWIcSN
|
||
rKKEdU823RDEwVi91AmyjmXP+KndUo7Q1DWeIM6wDTHzzDus5fnNScR1o+3f
|
||
Q88jR1Osi9kAM0RUs4mFEqazPSQcbcBQzpag16GENNc0ODmS3iqV66VKwQSW
|
||
Jth1SYXrjPWGlUYds81B9QhB4/QICQzcgXNSRzj8q4Mqqs+tIqG02si6kN1y
|
||
TSWvsFRNRMQAPLyc/XDEKTc8MarVzlS6TIh/YxFJUmxk3SkoZbkiFngV6gAu
|
||
kpLDybzAoKHvmggUhFullysqCKxki6e0lluqGejV4ZizJFbprJ41Rd1SZV8K
|
||
1wV7L1nppkZrcsakukZ1ijM5u0eHZlh1enV2Ok476LxqUb/G6zhw7HHIooS8
|
||
CxcyRcl0hhBBnLOsd7iP5NkrxObxCyFe9DB00izMaYxbwNkcfw3nz8aMOgxd
|
||
Jjcy2afsqhAQ9G59FuBqnsCXNMpaNnqBEqbWnGwJ6J3A7auuee+SvtN2EHtV
|
||
7ou6LUAdAjQndKd9qu4iSV+jGMN4LZatO3hIofW0xCOWj5hbova9ntEuAxbW
|
||
W5Dl+8bc1qpaIlLwaUIcYQ0jj4xInQB8rfYFk3ROreleg+CgpAhHXx88UNYE
|
||
wURKDJyKs6QphvroakePxK0LXVYJhOk8VUxhjnEfZTiN+5qQzAPLbKOie5V5
|
||
LDx91luSClwrhW5/1QOQBgYOZoqDlTUc+vrVVVbzjq8I9pLWhA2Z6EjlljGA
|
||
OYkxLBAB2LvUxHX0HezUK+100zU9CweRjDhcLI8kxzH4quzos7pGr7qvRkqm
|
||
jHKkw+qNOoro0kHhT8CW8h/71SUnZr3O4kwuKxyac/u+SujeIqFUGCT2Lsw4
|
||
VAmEtyCEEZiRggAQc52y1FFO1L3nzVjGOEOEBeJpTEEJF4pPOOYND2ePZ0dv
|
||
Ed8+ezwjRD2TgR6dn1wEkD19igVMPdj+YGTy8POf0EJ9ZdBLHyLmeXUDtPzO
|
||
3gy2A50IkhKBKljvKhETklBo5z30DQMnLOhRtSNloqLFG6bc/q4QeCJ4EsxA
|
||
vduaMK2JsHklWUK/Ee3zDeGcf3Io9uxxAfBuxKu5SUyUomOpyD/r8bKrkWH/
|
||
ikDqNFJfsXfoiobIpRmV2p7RfHDx8mq1ES5/FIrWYBQtwNHRgEYoddfKSwoj
|
||
SgcqJZlDj1xexcwa94NLB7DqN0EysdMXtcxOwVq7tfRocETbOyfq85Prr1wO
|
||
A8DCUbygBd7xUie3bEO4RMje4L5UxXmYSYgCDe9/+RDBXGHg3VBIEOnCqiKF
|
||
5hgHhldCOJ8TNnRxOGJ3kg9L3NGYvHHUHai1++n0xYxBYTl41zU8k5t8Je/Q
|
||
mL/HCRJo4jOkFT9bc216azGUXafay/mW/BnSKhXHzmUtvDGUZCVrHEUSY0gQ
|
||
9lGl4gGJ5D4awvmDxhlkTHs2v5IY5v05hv1JL/YGfXgQIok7tbD3RIId96pE
|
||
bjum07IN4NW1ITlcWlUxdsuNYXZxRlDqcbi2h2GHni4l4kNfSQYAX5ydQdfQ
|
||
pT67JEccA/u5PzOvBOMEz4FPqLE4r2Fie0IQJhsqArKVFckmHuLaw67FQl8B
|
||
sDLO43V0bgwL0jnSr9xRQrbXAS3JhsupdsjFWJyxE/tP7J/i5S61DdXEqe1U
|
||
3LUds7+BQSBaVOrRreovC9ihHImJQ9QLWJHMcyU7O5m6AUeoXHAzs7GkzTAK
|
||
uLH8hbRK4ClEfPYYZAri7mwnTYEMXiCTiSRv8ixjOTvivPpph4J10Au6/CbU
|
||
uDyA16YIrF9EaOgPg4u8XqtbeGmc5924L5pBQMGdihwmyS6Vb1EkJ1xYADv0
|
||
m9lvI5NYHOCB/EqkLN7dX/6QsHdqn/CZMa8aAjKnwpj4KRaiJAbHA4jn4A16
|
||
FzlR+45p3ey7UOVDdIH6HAG5dYl6EXSZE7SUDTIbG83cDZoMkSPyTYbepKbv
|
||
tE+VdrHnYSwxAO33WZH2It1CoCp0P/v7JgjWbRaDqxewupKQKNjvWQ8Rh48P
|
||
dkHjA8GbQ8IYASYEBdsCWq/au0xh77qfHGonemhx329AAgVFlUF+UElF1Cvd
|
||
LXYAw1ZstGRUIPMdAv65P64Lw4yRiKCeHFrEkdQseMZuQK/MEiotu9uKCB+Q
|
||
hemODj458dCTQVFvs5LtQXb5OZ4AND0pCZ/X5nOOuIdBhhlSLhmLO4nsLPDM
|
||
ki48ERmyP7qjQ4g/c1DMRyfuCukkJMPxFKJtCd/DXr6VLjBlI9VNUyaXw0vj
|
||
KKvDRRXBh6E0UYG5jGnuSeXaao0FHiGKlccsGSp6cg2P75pVZPqdibFiQHd7
|
||
PFAP2RGhUxumenCCRA16o5uW4GXTFNLIskmq2tMeNOUnd005BVmHUx6EQxGS
|
||
U/sxxbIjNRmmM7wy5M6JP6Y3FOVFFML0TuvtMJACZUA4EAHONxBEQ6blemOq
|
||
47VKFf1hUg3K/8Ck613GRkXZmKawqu2qcNEGRixRXJE1DzBrqDwPbzpDwd6r
|
||
JBTF/ThogW7yjHg2mCn5GhuME8toMdxKJwa8wOqbbw3SPp2eKotu16ECI7+3
|
||
OEHcyaEKZVDsWSZDbPANptL2BWPvCvRAiCiWTmc/3F0gEbM3AiH9DJ2+20WE
|
||
d4h1TaDTkK0Re9maODRXFtd1vgRUJ/ESDMugCAY1horivl47uz6lFzpZHeWQ
|
||
LlF08gVOcRJkXDdBd6VrnAJWnbQXlVSGS2LwTp9QuzxQWaH27fmHleyc70s7
|
||
Qvyefqc6RbwGtE6DHyA3xl7hH52x3RrMYnADKpRYQpbXEygeD0mhS6/XOQL6
|
||
Kyd2Curm2wH84ANpkI3aVZ4T0dfxuAyvPgD7F3S7EZXepOptlCnEHwO6sxc+
|
||
mEh+JWSAZGQTH5Ml7UytagyghQ/2SYUdPz+5LuYSPeDBhYDJLsnqJxYg5w3f
|
||
/MW1fGgaUYVBud1VmC/137mIcXf7duhvVYgX5NKAcqR9LUhuywHcRdrzzmMt
|
||
KAY00W6k+6mHAbmg98LdSbl5eJr7ITHdPBD1WBLRZzz55GOdz26QNeLEon3S
|
||
B+rSp+nSXlxcvYWuwSB3MzRa3SDNJdcts1zwqHs3OSfuvvSFRnm+uk2SxT0k
|
||
PlbOxJTdjnKECGzT/h6S53HqPgqOjkPPMn6l9gLXZDe/uoLjyRPOZKe4swuS
|
||
glgeU8G78xpsyj4YKXA0vIvGwLsg16K8SMmd3vY4GCSGv3Q15s6SCt+PAtOt
|
||
jSGLTy441QJZHVUpk3vOPpk1a6ob84aZlSmf7n2qsth83a/kw0LX3nIEhEsM
|
||
VVa4liKIVeoIW501f+cAXDw/UUDT3bEHG90pr5CWexeForYJIdlswmHstvOP
|
||
wg2AhObfO0X91jx6ZzrPv2LbQPjcx+AEx0ra6hapHbkDc44YF+WII0q4PrZ4
|
||
l/KPdbC0D4gHzXclr7PbPSXs3VJd1n4l1sGKtHB3Ct2c0OCN1fvX26Gk3y/Q
|
||
/yr2i/ebzAPGJbDG4F6O/JYTGqamOuqEYjmgFbHwc0tXrIT7OCD/6h4WuLcq
|
||
TtZYhuJXa9r9q0O3HnBhJkUdaCKH7hDprwKkdBEVim4Plu4NykqH+mtoq0Qv
|
||
PCkyDCc2Dguow5XWZJqczV7P9syS4Z28KeM5jH9QS6uWOCFuOCXmwyMz42lf
|
||
b1sFl/zJVojL7ON9sHFmCVIKnlxrCYuOMlPoY8lQMIm9hoExnvkJ/kIp+93s
|
||
DGo1yoRjo3uSOJ+mB9Hbdzze+0x82oOkh/FnOxf199Dp4fiH8eux/fCWOTts
|
||
vds+Q7Dvj9/7CzvtBwZ3T78D98uFW4n6a5Ko/W5GJ7Tf0RiDpEY2fmSa3aK9
|
||
X8M5qUKytWqhP1BMDieAf/xyXtjjh1/IA5EPFlS4eRftoi0dAj3D/YvtkgVZ
|
||
2PDvXAw/H+xbSP8covUdrSK9z1FVD85nSFDcT2nS8HQASTRSe/7XXyi6FHAB
|
||
pC589o5uu+7dduLoP5RzYymrEDDhPYp0Co1pFBmTIcKSv4sg4AKeN6Wp6H6+
|
||
OYOVHyIo8whNp862xqlpgkMnzPmuPYX6fO8fv9n9dBDQG16HHP6ZBgRmoTid
|
||
JcAG/9MXH6dcga6q70dU4pqiEL/yyvMYIGYK31tlHC43+P3XkQePfinbpDN+
|
||
0b+UkP/jCgQqycosRPzXHKjqZIeU/wdTDktXx2kAAA==
|
||
|
||
-->
|
||
|
||
</rfc>
|
||
|