1369 lines
50 KiB
XML
1369 lines
50 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-gap-analysis-00" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
|
||
<front>
|
||
<title abbrev="Agent Gap Analysis">Gap Analysis for Autonomous Agent Protocols</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>
|
||
|
||
|
||
<abstract>
|
||
|
||
|
||
<?line 53?>
|
||
|
||
<t>This document maps the IETF autonomous agent landscape,
|
||
identifies eleven gap areas where standardization is absent
|
||
or insufficient, and introduces six companion drafts that
|
||
address the most critical gaps. Over 260 IETF drafts touch
|
||
on agent communication, identity, safety, and operations,
|
||
yet no single reference architecture ties them together.
|
||
This gap analysis provides a structured roadmap for the
|
||
standards work needed to enable safe, interoperable, and
|
||
auditable autonomous agent ecosystems.</t>
|
||
|
||
|
||
|
||
</abstract>
|
||
|
||
|
||
|
||
</front>
|
||
|
||
<middle>
|
||
|
||
|
||
<?line 65?>
|
||
|
||
<section anchor="introduction"><name>Introduction</name>
|
||
|
||
<t>Autonomous software agents are increasingly deployed in
|
||
network management, cloud orchestration, supply-chain
|
||
logistics, and AI-driven workflows. Over 260 IETF drafts
|
||
touch on aspects of agent communication, identity, safety,
|
||
and operations. However, these efforts remain fragmented:
|
||
no single reference architecture ties them together, and
|
||
several critical capabilities lack any standardization at
|
||
all.</t>
|
||
|
||
<t>This document provides three contributions:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>A reference architecture that organizes agent
|
||
capabilities into layers (Section 3).</t>
|
||
<t>A survey of existing IETF work relevant to autonomous
|
||
agents (Section 4).</t>
|
||
<t>A gap analysis identifying eleven areas where new or
|
||
extended standards are needed, together with a roadmap
|
||
of six companion drafts that address the most critical
|
||
gaps (Sections 5 and 6).</t>
|
||
</list></t>
|
||
|
||
<t>The intended audience includes working group chairs,
|
||
area directors, and protocol designers evaluating where
|
||
autonomous-agent standardization efforts should focus.</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>
|
||
|
||
<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 throughout this document:</t>
|
||
|
||
<dl>
|
||
<dt>Agent:</dt>
|
||
<dd>
|
||
<t>A software component that acts on behalf of a principal
|
||
(human or organizational) to perform tasks, communicate
|
||
with other agents, or interact with external systems.</t>
|
||
</dd>
|
||
<dt>Autonomous Agent:</dt>
|
||
<dd>
|
||
<t>An agent capable of executing multi-step tasks without
|
||
continuous human supervision, including making decisions
|
||
based on policy, context, and environmental state.</t>
|
||
</dd>
|
||
<dt>Agent Ecosystem:</dt>
|
||
<dd>
|
||
<t>The set of agents, their principals, the policies that
|
||
govern them, and the infrastructure services (identity,
|
||
discovery, audit) they rely on.</t>
|
||
</dd>
|
||
<dt>DAG (Directed Acyclic Graph):</dt>
|
||
<dd>
|
||
<t>A graph structure used to represent multi-step agent
|
||
execution plans where tasks have dependency ordering
|
||
but no circular dependencies.</t>
|
||
</dd>
|
||
<dt>HITL (Human-in-the-Loop):</dt>
|
||
<dd>
|
||
<t>A control pattern in which a human operator must
|
||
approve, modify, or reject an agent action before
|
||
it takes effect.</t>
|
||
</dd>
|
||
<dt>ECT (Execution Context Token):</dt>
|
||
<dd>
|
||
<t>A cryptographically signed token that carries the
|
||
execution context (task identity, delegated authority,
|
||
constraints) for an agent action. See
|
||
<xref target="I-D.nennemann-wimse-ect"/>.</t>
|
||
</dd>
|
||
<dt>ACP (Agent Context Policy):</dt>
|
||
<dd>
|
||
<t>A policy document that specifies permitted behaviors,
|
||
resource limits, and escalation rules for an agent
|
||
within a given execution context. See
|
||
<xref target="I-D.nennemann-agent-dag-hitl-safety"/>.</t>
|
||
</dd>
|
||
<dt>Behavioral Attestation:</dt>
|
||
<dd>
|
||
<t>A verifiable claim that an agent's runtime behavior
|
||
conforms to a declared policy or behavioral profile.</t>
|
||
</dd>
|
||
<dt>Cascade Failure:</dt>
|
||
<dd>
|
||
<t>A failure mode in which an error in one agent
|
||
propagates through a multi-agent workflow, causing
|
||
successive agents to fail or produce incorrect
|
||
results.</t>
|
||
</dd>
|
||
<dt>Consensus Protocol:</dt>
|
||
<dd>
|
||
<t>A protocol by which multiple agents reach agreement
|
||
on a shared decision, state, or action plan.</t>
|
||
</dd>
|
||
<dt>Override Signal:</dt>
|
||
<dd>
|
||
<t>A message from a human operator or supervisory system
|
||
that instructs an agent to halt, modify, or roll back
|
||
its current action.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="reference-architecture"><name>Reference Architecture</name>
|
||
|
||
<t>The following diagram presents a layered reference
|
||
architecture for autonomous agent ecosystems. Each layer
|
||
identifies the relevant gap areas addressed by this
|
||
analysis.</t>
|
||
|
||
<figure title="Agent Ecosystem Reference Architecture" anchor="fig-arch"><artwork type="ascii-art"><![CDATA[
|
||
+-------------------------------------------------------------+
|
||
| HUMAN OPERATORS |
|
||
| [Override & HITL Layer -- GAP 7] |
|
||
+-------------------------------------------------------------+
|
||
| AGENT INTERACTION LAYER |
|
||
| +---------+ +---------+ +---------+ +---------+ |
|
||
| | Agent A |<>| Agent B |<>| Agent C |<>| Agent D | |
|
||
| +----+----+ +----+----+ +----+----+ +----+----+ |
|
||
| | GAP 3: | GAP 10: | GAP 1: | |
|
||
| | Consensus | Cap.Neg. | Behav. | |
|
||
| | | | Verif. | |
|
||
+-------+------------+------------+------------+--------------+
|
||
| EXECUTION LAYER (ECT) |
|
||
| DAG Execution | Checkpoints | Rollback | Circuit Breakers |
|
||
| [GAP 2: Cascade Prevention] [GAP 4: Rollback] |
|
||
+-------------------------------------------------------------+
|
||
| POLICY & GOVERNANCE LAYER |
|
||
| ACP-DAG-HITL | Trust Scoring | Assurance Profiles |
|
||
| [GAP 5: Federated Privacy] [GAP 6: Cross-Domain Audit] |
|
||
+-------------------------------------------------------------+
|
||
| INFRASTRUCTURE LAYER |
|
||
| Identity | Discovery | Registration | Protocol Bridges |
|
||
| [GAP 8: Cross-Protocol] [GAP 9: Resource Accounting] |
|
||
| [GAP 11: Performance Benchmarking] |
|
||
+-------------------------------------------------------------+
|
||
]]></artwork></figure>
|
||
|
||
<t>The Human Operators layer provides override and
|
||
human-in-the-loop controls (Gap 7). The Agent Interaction
|
||
layer is where agents communicate, negotiate capabilities
|
||
(Gap 10), reach consensus (Gap 3), and undergo behavioral
|
||
verification (Gap 1). The Execution layer manages DAG-based
|
||
workflows with cascade prevention (Gap 2) and rollback
|
||
(Gap 4). The Policy and Governance layer enforces privacy
|
||
in federated learning (Gap 5) and cross-domain audit trails
|
||
(Gap 6). The Infrastructure layer handles identity,
|
||
discovery, cross-protocol migration (Gap 8), resource
|
||
accounting (Gap 9), and performance benchmarking (Gap 11).</t>
|
||
|
||
</section>
|
||
<section anchor="existing-ietf-work"><name>Existing IETF Work</name>
|
||
|
||
<t>This section briefly surveys existing IETF efforts relevant
|
||
to autonomous agent protocols.</t>
|
||
|
||
<section anchor="wimse-workload-identity-in-multi-system-environments"><name>WIMSE (Workload Identity in Multi-System Environments)</name>
|
||
|
||
<t>The WIMSE working group addresses workload identity and
|
||
Execution Context Tokens (ECTs) <xref target="I-D.nennemann-wimse-ect"/>.
|
||
ECTs provide the foundation for carrying delegated authority
|
||
and task context across agent boundaries.</t>
|
||
|
||
</section>
|
||
<section anchor="rats-remote-attestation-procedures"><name>RATS (Remote ATtestation procedureS)</name>
|
||
|
||
<t>RATS defines architectures and protocols for remote
|
||
attestation <xref target="RFC9334"/>. Attestation evidence and
|
||
appraisal are directly applicable to verifying agent
|
||
behavioral claims.</t>
|
||
|
||
</section>
|
||
<section anchor="oauth-and-gnap"><name>OAuth and GNAP</name>
|
||
|
||
<t>OAuth 2.0 and the Grant Negotiation and Authorization
|
||
Protocol (GNAP) provide authorization frameworks.
|
||
Transaction tokens and token exchange mechanisms are
|
||
relevant to agent-to-agent delegation chains.</t>
|
||
|
||
</section>
|
||
<section anchor="scitt-supply-chain-integrity-transparency-and-trust"><name>SCITT (Supply Chain Integrity, Transparency, and Trust)</name>
|
||
|
||
<t>SCITT defines transparency services for supply chain
|
||
artifacts. Its append-only log model is relevant to
|
||
agent audit trails and provenance tracking.</t>
|
||
|
||
</section>
|
||
<section anchor="nmop-network-management-operations"><name>NMOP (Network Management Operations)</name>
|
||
|
||
<t>The NMOP working group focuses on network management
|
||
operations including intent-based management and
|
||
autonomous network functions. Agent-driven network
|
||
management is a primary use case for the gaps identified
|
||
in this document.</t>
|
||
|
||
</section>
|
||
<section anchor="industry-protocols-a2a-and-mcp"><name>Industry Protocols: A2A and MCP</name>
|
||
|
||
<t>The Agent-to-Agent (A2A) protocol and Model Context
|
||
Protocol (MCP) are emerging industry standards for agent
|
||
communication. While not IETF specifications, they
|
||
inform the gap analysis by highlighting capabilities
|
||
that lack standardized, interoperable definitions.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="gap-analysis"><name>Gap Analysis</name>
|
||
|
||
<t>This section identifies eleven gaps in the current
|
||
standards landscape for autonomous agent protocols.
|
||
Gaps are classified by severity:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>CRITICAL: No existing standard addresses the problem;
|
||
failure to standardize poses immediate safety or
|
||
interoperability risks.</t>
|
||
<t>HIGH: Partial coverage exists but is insufficient for
|
||
production autonomous agent deployments.</t>
|
||
<t>MEDIUM: The gap affects efficiency or completeness but
|
||
does not pose immediate safety risks.</t>
|
||
</list></t>
|
||
|
||
<section anchor="gap-1"><name>Gap 1: Agent Behavioral Verification</name>
|
||
|
||
<dl>
|
||
<dt>Severity:</dt>
|
||
<dd>
|
||
<t>CRITICAL</t>
|
||
</dd>
|
||
<dt>Category:</dt>
|
||
<dd>
|
||
<t>AI Safety</t>
|
||
</dd>
|
||
<dt>Problem Statement:</dt>
|
||
<dd>
|
||
<t>Autonomous agents operating in production environments
|
||
currently lack any standardized mechanism for runtime
|
||
verification of policy compliance. While RATS
|
||
<xref target="RFC9334"/> provides attestation for platform integrity,
|
||
no equivalent exists for verifying that an agent's
|
||
observed behavior conforms to its declared behavioral
|
||
profile or policy constraints.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>Without behavioral verification, operators cannot
|
||
distinguish between an agent that faithfully executes
|
||
its policy and one that has drifted, been compromised,
|
||
or is operating outside its intended parameters. This
|
||
is especially dangerous in multi-agent workflows where
|
||
one misbehaving agent can corrupt downstream results.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>The gap extends to the absence of standardized
|
||
behavioral profiles, verification evidence formats,
|
||
and appraisal procedures specific to agent conduct.</t>
|
||
</dd>
|
||
<dt>Impact if Unaddressed:</dt>
|
||
<dd>
|
||
<t>Undetected policy violations in autonomous agents
|
||
could cause safety incidents, data breaches, or
|
||
cascading failures in critical infrastructure.</t>
|
||
</dd>
|
||
<dt>Existing Partial Coverage:</dt>
|
||
<dd>
|
||
<t>RATS <xref target="RFC9334"/> covers platform attestation but not
|
||
behavioral compliance. ACP-DAG-HITL
|
||
<xref target="I-D.nennemann-agent-dag-hitl-safety"/> defines
|
||
policies but not verification mechanisms.</t>
|
||
</dd>
|
||
<dt>Companion Draft:</dt>
|
||
<dd>
|
||
<t><xref target="I-D.nennemann-agent-behavioral-verification"/></t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="gap-2"><name>Gap 2: Agent Failure Cascade Prevention</name>
|
||
|
||
<dl>
|
||
<dt>Severity:</dt>
|
||
<dd>
|
||
<t>CRITICAL</t>
|
||
</dd>
|
||
<dt>Category:</dt>
|
||
<dd>
|
||
<t>AI Safety, Resilience</t>
|
||
</dd>
|
||
<dt>Problem Statement:</dt>
|
||
<dd>
|
||
<t>Multi-agent workflows create dependency chains where a
|
||
failure in one agent can propagate to downstream agents,
|
||
causing cascade failures. No standardized mechanism
|
||
exists for circuit breakers, failure isolation, or
|
||
cascade containment in agent-to-agent interactions.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>Current practice relies on ad-hoc timeout and retry
|
||
logic that is neither interoperable nor sufficient for
|
||
complex DAG-structured workflows. Agents from
|
||
different vendors or administrative domains have no
|
||
common way to signal failure states or trigger
|
||
containment procedures.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>The absence of cascade prevention is especially
|
||
critical in network management scenarios where agent
|
||
failures could propagate to affect live network
|
||
operations.</t>
|
||
</dd>
|
||
<dt>Impact if Unaddressed:</dt>
|
||
<dd>
|
||
<t>A single agent failure could cascade through an entire
|
||
multi-agent deployment, causing widespread service
|
||
disruption with no automated containment.</t>
|
||
</dd>
|
||
<dt>Existing Partial Coverage:</dt>
|
||
<dd>
|
||
<t>ECT <xref target="I-D.nennemann-wimse-ect"/> provides execution
|
||
context but no failure containment semantics.</t>
|
||
</dd>
|
||
<dt>Companion Draft:</dt>
|
||
<dd>
|
||
<t><xref target="I-D.nennemann-agent-cascade-prevention"/></t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="gap-3"><name>Gap 3: Multi-Agent Consensus Protocols</name>
|
||
|
||
<dl>
|
||
<dt>Severity:</dt>
|
||
<dd>
|
||
<t>HIGH</t>
|
||
</dd>
|
||
<dt>Category:</dt>
|
||
<dd>
|
||
<t>A2A Protocols</t>
|
||
</dd>
|
||
<dt>Problem Statement:</dt>
|
||
<dd>
|
||
<t>When multiple agents must agree on a shared decision
|
||
(e.g., a network configuration change, a resource
|
||
allocation plan, or a coordinated response to an
|
||
incident), no standardized consensus protocol exists
|
||
for agent-to-agent agreement.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>Distributed systems consensus protocols (Raft, Paxos)
|
||
are designed for replicated state machines, not for
|
||
heterogeneous agents with different capabilities,
|
||
trust levels, and policy constraints. Agent consensus
|
||
requires additional semantics such as weighted voting,
|
||
capability-based participation, and policy-constrained
|
||
proposals.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>Without a standard protocol, multi-agent coordination
|
||
relies on proprietary mechanisms that are not
|
||
interoperable across vendors or administrative domains.</t>
|
||
</dd>
|
||
<dt>Impact if Unaddressed:</dt>
|
||
<dd>
|
||
<t>Multi-vendor agent deployments cannot coordinate
|
||
decisions, limiting autonomous agents to single-vendor
|
||
silos.</t>
|
||
</dd>
|
||
<dt>Existing Partial Coverage:</dt>
|
||
<dd>
|
||
<t>No existing IETF work directly addresses multi-agent
|
||
consensus.</t>
|
||
</dd>
|
||
<dt>Companion Draft:</dt>
|
||
<dd>
|
||
<t><xref target="I-D.nennemann-agent-consensus"/></t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="gap-4"><name>Gap 4: Real-Time Agent Rollback Mechanisms</name>
|
||
|
||
<dl>
|
||
<dt>Severity:</dt>
|
||
<dd>
|
||
<t>HIGH</t>
|
||
</dd>
|
||
<dt>Category:</dt>
|
||
<dd>
|
||
<t>Resilience, Operations</t>
|
||
</dd>
|
||
<dt>Problem Statement:</dt>
|
||
<dd>
|
||
<t>When an autonomous agent takes an action that produces
|
||
unintended consequences, no standardized mechanism
|
||
exists for rolling back the action and restoring
|
||
the previous state. This is particularly important
|
||
for network management agents that modify device
|
||
configurations.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>Rollback requires standardized checkpointing, state
|
||
snapshots, and undo semantics that work across agent
|
||
boundaries and administrative domains. Current
|
||
rollback mechanisms (e.g., NETCONF confirmed-commit)
|
||
are protocol-specific and do not generalize to
|
||
arbitrary agent actions.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>The lack of rollback is compounded in multi-agent
|
||
workflows where multiple agents may have taken
|
||
coordinated actions that must be reversed as a unit.</t>
|
||
</dd>
|
||
<dt>Impact if Unaddressed:</dt>
|
||
<dd>
|
||
<t>Operators cannot safely deploy autonomous agents for
|
||
critical operations without manual intervention
|
||
capability for every action.</t>
|
||
</dd>
|
||
<dt>Existing Partial Coverage:</dt>
|
||
<dd>
|
||
<t>NETCONF confirmed-commit provides rollback for
|
||
configuration changes only.</t>
|
||
</dd>
|
||
<dt>Companion Draft:</dt>
|
||
<dd>
|
||
<t><xref target="I-D.nennemann-agent-cascade-prevention"/></t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="gap-5"><name>Gap 5: Federated Agent Learning Privacy</name>
|
||
|
||
<dl>
|
||
<dt>Severity:</dt>
|
||
<dd>
|
||
<t>HIGH</t>
|
||
</dd>
|
||
<dt>Category:</dt>
|
||
<dd>
|
||
<t>Privacy, Federated Systems</t>
|
||
</dd>
|
||
<dt>Problem Statement:</dt>
|
||
<dd>
|
||
<t>Agents that participate in federated learning or
|
||
share operational data across administrative domains
|
||
require privacy guarantees that go beyond transport
|
||
encryption. No IETF specification addresses the
|
||
privacy requirements of federated agent learning,
|
||
including differential privacy parameters, data
|
||
minimization for shared agent telemetry, and
|
||
consent management for cross-domain data sharing.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>As agents are deployed across organizational
|
||
boundaries, the data they generate and share can
|
||
reveal sensitive information about network topology,
|
||
operational patterns, and business logic. Privacy-
|
||
preserving mechanisms specific to agent interactions
|
||
are needed.</t>
|
||
</dd>
|
||
<dt>Impact if Unaddressed:</dt>
|
||
<dd>
|
||
<t>Organizations will be unable to participate in
|
||
federated agent ecosystems without unacceptable
|
||
privacy risks, limiting the value of multi-domain
|
||
agent deployments.</t>
|
||
</dd>
|
||
<dt>Existing Partial Coverage:</dt>
|
||
<dd>
|
||
<t>General privacy frameworks exist but none address
|
||
agent-specific federated learning scenarios.</t>
|
||
</dd>
|
||
<dt>Companion Draft:</dt>
|
||
<dd>
|
||
<t><xref target="I-D.nennemann-agent-federation-privacy"/></t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="gap-6"><name>Gap 6: Cross-Domain Agent Audit Trails</name>
|
||
|
||
<dl>
|
||
<dt>Severity:</dt>
|
||
<dd>
|
||
<t>HIGH</t>
|
||
</dd>
|
||
<dt>Category:</dt>
|
||
<dd>
|
||
<t>Audit, Compliance</t>
|
||
</dd>
|
||
<dt>Problem Statement:</dt>
|
||
<dd>
|
||
<t>When agents operate across multiple administrative
|
||
domains, their actions must be auditable end-to-end.
|
||
No standardized format exists for cross-domain agent
|
||
audit trails that preserves causal ordering, links
|
||
related actions across domain boundaries, and provides
|
||
tamper-evident logging.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>Execution Audit Tokens <xref target="I-D.nennemann-exec-audit"/>
|
||
provide per-action audit records, but no standard
|
||
defines how these records are aggregated, correlated,
|
||
and queried across domains. SCITT provides
|
||
transparency log primitives but does not define
|
||
agent-specific audit semantics.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>Regulatory and compliance requirements increasingly
|
||
demand end-to-end audit trails for automated
|
||
decision-making, making this gap urgent for
|
||
enterprise deployments.</t>
|
||
</dd>
|
||
<dt>Impact if Unaddressed:</dt>
|
||
<dd>
|
||
<t>Organizations cannot demonstrate compliance for
|
||
cross-domain agent operations, blocking adoption
|
||
in regulated industries.</t>
|
||
</dd>
|
||
<dt>Existing Partial Coverage:</dt>
|
||
<dd>
|
||
<t>SCITT provides transparency log primitives.
|
||
<xref target="I-D.nennemann-exec-audit"/> defines per-action
|
||
audit tokens.</t>
|
||
</dd>
|
||
<dt>Companion Draft:</dt>
|
||
<dd>
|
||
<t><xref target="I-D.nennemann-agent-cross-domain-audit"/></t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="gap-7"><name>Gap 7: Human Override Standardization</name>
|
||
|
||
<dl>
|
||
<dt>Severity:</dt>
|
||
<dd>
|
||
<t>HIGH</t>
|
||
</dd>
|
||
<dt>Category:</dt>
|
||
<dd>
|
||
<t>AI Safety, Human Control</t>
|
||
</dd>
|
||
<dt>Problem Statement:</dt>
|
||
<dd>
|
||
<t>Autonomous agents must always be subject to human
|
||
override, but no cross-vendor protocol exists for
|
||
sending override signals to agents. Override
|
||
requirements include emergency stop, graceful pause,
|
||
parameter modification, and forced rollback.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>Current override mechanisms are vendor-specific and
|
||
cannot be used in multi-vendor agent deployments.
|
||
ACP-DAG-HITL <xref target="I-D.nennemann-agent-dag-hitl-safety"/>
|
||
defines when human approval is required but does not
|
||
specify the protocol for delivering override signals
|
||
to running agents.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>The absence of a standard override protocol creates
|
||
a significant safety risk: if an agent misbehaves,
|
||
the operator may not have a reliable way to stop it
|
||
if the agent comes from a different vendor than the
|
||
management platform.</t>
|
||
</dd>
|
||
<dt>Impact if Unaddressed:</dt>
|
||
<dd>
|
||
<t>Operators lose the ability to control autonomous
|
||
agents in emergency situations, creating unacceptable
|
||
safety risks.</t>
|
||
</dd>
|
||
<dt>Existing Partial Coverage:</dt>
|
||
<dd>
|
||
<t>ACP-DAG-HITL <xref target="I-D.nennemann-agent-dag-hitl-safety"/>
|
||
defines HITL policies but not override delivery.</t>
|
||
</dd>
|
||
<dt>Companion Draft:</dt>
|
||
<dd>
|
||
<t><xref target="I-D.nennemann-agent-override-protocol"/></t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="gap-8"><name>Gap 8: Cross-Protocol Agent Migration</name>
|
||
|
||
<dl>
|
||
<dt>Severity:</dt>
|
||
<dd>
|
||
<t>MEDIUM</t>
|
||
</dd>
|
||
<dt>Category:</dt>
|
||
<dd>
|
||
<t>Interoperability</t>
|
||
</dd>
|
||
<dt>Problem Statement:</dt>
|
||
<dd>
|
||
<t>Agents may need to migrate between protocol
|
||
environments (e.g., from an A2A-based system to an
|
||
MCP-based system) while preserving execution context,
|
||
identity, and accumulated state. No standard defines
|
||
how agent context is translated or preserved across
|
||
protocol boundaries.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>As the agent ecosystem matures, agents will
|
||
increasingly operate in heterogeneous protocol
|
||
environments. Without migration standards, agents
|
||
are locked into specific protocol ecosystems.</t>
|
||
</dd>
|
||
<dt>Impact if Unaddressed:</dt>
|
||
<dd>
|
||
<t>Agent deployments become fragmented across protocol
|
||
silos, reducing interoperability and increasing
|
||
operational complexity.</t>
|
||
</dd>
|
||
<dt>Existing Partial Coverage:</dt>
|
||
<dd>
|
||
<t>ECT <xref target="I-D.nennemann-wimse-ect"/> provides a
|
||
protocol-neutral context token but does not define
|
||
migration procedures.</t>
|
||
</dd>
|
||
<dt>Companion Draft:</dt>
|
||
<dd>
|
||
<t><xref target="I-D.nennemann-agent-federation-privacy"/></t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="gap-9"><name>Gap 9: Agent Resource Accounting and Billing</name>
|
||
|
||
<dl>
|
||
<dt>Severity:</dt>
|
||
<dd>
|
||
<t>MEDIUM</t>
|
||
</dd>
|
||
<dt>Category:</dt>
|
||
<dd>
|
||
<t>Operations, Economics</t>
|
||
</dd>
|
||
<dt>Problem Statement:</dt>
|
||
<dd>
|
||
<t>Autonomous agents consume computational, network, and
|
||
API resources across administrative domains. No
|
||
standardized mechanism exists for tracking, reporting,
|
||
and reconciling resource consumption by agents,
|
||
especially in multi-domain scenarios where an agent's
|
||
actions incur costs in domains other than its own.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>Resource accounting is a prerequisite for sustainable
|
||
multi-domain agent ecosystems where organizations
|
||
need to track and charge for agent resource usage.</t>
|
||
</dd>
|
||
<dt>Impact if Unaddressed:</dt>
|
||
<dd>
|
||
<t>Organizations cannot accurately track or bill for
|
||
agent resource consumption, hindering commercial
|
||
multi-domain agent deployments.</t>
|
||
</dd>
|
||
<dt>Existing Partial Coverage:</dt>
|
||
<dd>
|
||
<t>No existing IETF work addresses agent-specific
|
||
resource accounting.</t>
|
||
</dd>
|
||
<dt>Companion Draft:</dt>
|
||
<dd>
|
||
<t><xref target="I-D.nennemann-agent-cross-domain-audit"/></t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="gap-10"><name>Gap 10: Agent Capability Negotiation</name>
|
||
|
||
<dl>
|
||
<dt>Severity:</dt>
|
||
<dd>
|
||
<t>MEDIUM</t>
|
||
</dd>
|
||
<dt>Category:</dt>
|
||
<dd>
|
||
<t>A2A Protocols</t>
|
||
</dd>
|
||
<dt>Problem Statement:</dt>
|
||
<dd>
|
||
<t>When agents interact, they need to discover and
|
||
negotiate each other's capabilities dynamically.
|
||
No standardized capability negotiation protocol
|
||
exists for agents to advertise their functions,
|
||
agree on interaction protocols, and establish
|
||
compatible communication parameters.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>Well-known URI <xref target="RFC8615"/> and HTTP <xref target="RFC9110"/>
|
||
provide discovery primitives, but agent capability
|
||
negotiation requires richer semantics including
|
||
versioning, conditional capabilities, and policy-
|
||
constrained capability advertisement.</t>
|
||
</dd>
|
||
<dt>Impact if Unaddressed:</dt>
|
||
<dd>
|
||
<t>Agent interactions require pre-configured knowledge
|
||
of peer capabilities, limiting dynamic composition
|
||
and ad-hoc agent collaboration.</t>
|
||
</dd>
|
||
<dt>Existing Partial Coverage:</dt>
|
||
<dd>
|
||
<t>HTTP content negotiation and well-known URIs provide
|
||
basic discovery but not agent-specific capability
|
||
negotiation.</t>
|
||
</dd>
|
||
<dt>Companion Draft:</dt>
|
||
<dd>
|
||
<t><xref target="I-D.nennemann-agent-consensus"/></t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="gap-11"><name>Gap 11: Agent Performance Benchmarking</name>
|
||
|
||
<dl>
|
||
<dt>Severity:</dt>
|
||
<dd>
|
||
<t>MEDIUM</t>
|
||
</dd>
|
||
<dt>Category:</dt>
|
||
<dd>
|
||
<t>Operations, Metrics</t>
|
||
</dd>
|
||
<dt>Problem Statement:</dt>
|
||
<dd>
|
||
<t>No standardized metrics or benchmarking methodology
|
||
exists for evaluating autonomous agent performance.
|
||
Without common metrics, operators cannot compare
|
||
agent implementations, set performance baselines,
|
||
or detect performance degradation.</t>
|
||
</dd>
|
||
<dt/>
|
||
<dd>
|
||
<t>Agent performance encompasses multiple dimensions:
|
||
task completion accuracy, latency, resource
|
||
efficiency, safety compliance rate, and behavioral
|
||
consistency. Standardized metrics and measurement
|
||
procedures are needed for each dimension.</t>
|
||
</dd>
|
||
<dt>Impact if Unaddressed:</dt>
|
||
<dd>
|
||
<t>Operators cannot objectively evaluate or compare
|
||
autonomous agent implementations, hindering
|
||
procurement and deployment decisions.</t>
|
||
</dd>
|
||
<dt>Existing Partial Coverage:</dt>
|
||
<dd>
|
||
<t>No existing IETF work addresses agent performance
|
||
benchmarking.</t>
|
||
</dd>
|
||
<dt>Companion Draft:</dt>
|
||
<dd>
|
||
<t><xref target="I-D.nennemann-agent-behavioral-verification"/></t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="companion-draft-roadmap"><name>Companion Draft Roadmap</name>
|
||
|
||
<t>The following table maps each companion draft to the
|
||
gaps it addresses and its priority level:</t>
|
||
|
||
<texttable title="Companion Draft Roadmap" anchor="tab-roadmap">
|
||
<ttcol align='left'>Companion Draft</ttcol>
|
||
<ttcol align='center'>Gaps</ttcol>
|
||
<ttcol align='center'>Priority</ttcol>
|
||
<c>draft-nennemann-agent-behavioral-verification</c>
|
||
<c>1, 11</c>
|
||
<c>CRITICAL</c>
|
||
<c>draft-nennemann-agent-cascade-prevention</c>
|
||
<c>2, 4</c>
|
||
<c>CRITICAL</c>
|
||
<c>draft-nennemann-agent-consensus</c>
|
||
<c>3, 10</c>
|
||
<c>HIGH</c>
|
||
<c>draft-nennemann-agent-cross-domain-audit</c>
|
||
<c>6, 9</c>
|
||
<c>HIGH</c>
|
||
<c>draft-nennemann-agent-override-protocol</c>
|
||
<c>7</c>
|
||
<c>HIGH</c>
|
||
<c>draft-nennemann-agent-federation-privacy</c>
|
||
<c>5, 8</c>
|
||
<c>HIGH</c>
|
||
</texttable>
|
||
|
||
<t>The dependency relationships between companion drafts
|
||
are shown below:</t>
|
||
|
||
<figure title="Companion Draft Dependencies" anchor="fig-deps"><artwork type="ascii-art"><![CDATA[
|
||
behavioral-verification ---+
|
||
| |
|
||
v |
|
||
cascade-prevention |
|
||
| |
|
||
v v
|
||
override-protocol cross-domain-audit
|
||
| |
|
||
v v
|
||
consensus federation-privacy
|
||
]]></artwork></figure>
|
||
|
||
<t>The behavioral-verification draft (Companion A) is
|
||
foundational because its behavioral attestation format
|
||
is used by the cascade-prevention and cross-domain-audit
|
||
drafts. The cascade-prevention draft (Companion B)
|
||
defines failure containment that the override-protocol
|
||
(Companion E) builds upon. The consensus draft
|
||
(Companion C) extends behavioral verification with
|
||
multi-agent agreement. The cross-domain-audit draft
|
||
(Companion D) provides the audit infrastructure that
|
||
federation-privacy (Companion F) adds privacy controls
|
||
to.</t>
|
||
|
||
</section>
|
||
<section anchor="security-considerations"><name>Security Considerations</name>
|
||
|
||
<t>The gaps identified in this document have direct security
|
||
implications:</t>
|
||
|
||
<dl>
|
||
<dt>Behavioral Verification (Gap 1):</dt>
|
||
<dd>
|
||
<t>Without runtime behavioral verification, compromised
|
||
or malfunctioning agents cannot be detected, creating
|
||
opportunities for attacks that exploit trusted agent
|
||
identities to perform unauthorized actions.</t>
|
||
</dd>
|
||
<dt>Cascade Prevention (Gap 2):</dt>
|
||
<dd>
|
||
<t>The absence of cascade containment creates a denial-
|
||
of-service vector where an attacker can compromise a
|
||
single agent to disrupt an entire multi-agent workflow.</t>
|
||
</dd>
|
||
<dt>Human Override (Gap 7):</dt>
|
||
<dd>
|
||
<t>Without standardized override protocols, safety-
|
||
critical agent actions may not be stoppable, creating
|
||
an unacceptable risk profile for autonomous
|
||
deployments.</t>
|
||
</dd>
|
||
<dt>Cross-Domain Audit (Gap 6):</dt>
|
||
<dd>
|
||
<t>Gaps in audit trails across domain boundaries create
|
||
opportunities for agents to take actions that evade
|
||
detection and accountability.</t>
|
||
</dd>
|
||
<dt>Federated Privacy (Gap 5):</dt>
|
||
<dd>
|
||
<t>Sharing agent operational data across domains without
|
||
adequate privacy controls can expose sensitive
|
||
organizational information, network topology, and
|
||
business logic.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
<t>Implementers of autonomous agent systems <bcp14>SHOULD</bcp14> treat the
|
||
CRITICAL and HIGH severity gaps as security requirements
|
||
and prioritize their resolution.</t>
|
||
|
||
</section>
|
||
<section anchor="iana-considerations"><name>IANA Considerations</name>
|
||
|
||
<t>This document has no IANA actions.</t>
|
||
|
||
</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>
|
||
|
||
|
||
|
||
</references>
|
||
|
||
<references title='Informative References' anchor="sec-informative-references">
|
||
|
||
|
||
|
||
<reference anchor="RFC9334">
|
||
<front>
|
||
<title>Remote ATtestation procedureS (RATS) Architecture</title>
|
||
<author fullname="H. Birkholz" initials="H." surname="Birkholz"/>
|
||
<author fullname="D. Thaler" initials="D." surname="Thaler"/>
|
||
<author fullname="M. Richardson" initials="M." surname="Richardson"/>
|
||
<author fullname="N. Smith" initials="N." surname="Smith"/>
|
||
<author fullname="W. Pan" initials="W." surname="Pan"/>
|
||
<date month="January" year="2023"/>
|
||
<abstract>
|
||
<t>In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.</t>
|
||
</abstract>
|
||
</front>
|
||
<seriesInfo name="RFC" value="9334"/>
|
||
<seriesInfo name="DOI" value="10.17487/RFC9334"/>
|
||
</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="RFC8615">
|
||
<front>
|
||
<title>Well-Known Uniform Resource Identifiers (URIs)</title>
|
||
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
|
||
<date month="May" year="2019"/>
|
||
<abstract>
|
||
<t>This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
|
||
<t>In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.</t>
|
||
</abstract>
|
||
</front>
|
||
<seriesInfo name="RFC" value="8615"/>
|
||
<seriesInfo name="DOI" value="10.17487/RFC8615"/>
|
||
</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>
|
||
<reference anchor="I-D.nennemann-exec-audit" target="https://datatracker.ietf.org/doc/draft-nennemann-exec-audit/">
|
||
<front>
|
||
<title>Cross-Domain Execution Audit Tokens</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
<reference anchor="I-D.nennemann-agent-behavioral-verification" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-behavioral-verification/">
|
||
<front>
|
||
<title>Agent Behavioral Verification and Performance Benchmarking</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
<reference anchor="I-D.nennemann-agent-cascade-prevention" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-cascade-prevention/">
|
||
<front>
|
||
<title>Agent Failure Cascade Prevention and Rollback</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
<reference anchor="I-D.nennemann-agent-consensus" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-consensus/">
|
||
<front>
|
||
<title>Multi-Agent Consensus and Capability Negotiation Protocols</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
<reference anchor="I-D.nennemann-agent-cross-domain-audit" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-cross-domain-audit/">
|
||
<front>
|
||
<title>Cross-Domain Agent Audit Trails and Resource Accounting</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
<reference anchor="I-D.nennemann-agent-override-protocol" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-override-protocol/">
|
||
<front>
|
||
<title>Standardized Human Override Protocol for Autonomous Agents</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
<reference anchor="I-D.nennemann-agent-federation-privacy" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-federation-privacy/">
|
||
<front>
|
||
<title>Federated Agent Learning Privacy and Cross-Protocol Migration</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
|
||
|
||
</references>
|
||
|
||
</references>
|
||
|
||
|
||
<?line 791?>
|
||
|
||
<section anchor="acknowledgments"><name>Acknowledgments</name>
|
||
|
||
<t>The author thanks the participants of the WIMSE, RATS,
|
||
and NMOP working groups for discussions that informed
|
||
this analysis.</t>
|
||
|
||
</section>
|
||
|
||
|
||
</back>
|
||
|
||
<!-- ##markdown-source:
|
||
H4sIAAAAAAAAA7Vd63YbOXL+309Rkc9JpCzJsWzPjdlswpE1ts6xZEWSd7Jn
|
||
z/wAu0ESUTfQA6Alc0eeZ8mz5MlyqgpAo3mR7R2vf8ySYjcuVYW6fFWFHY/H
|
||
hVe+llM4eCVamGlRr51ysDAWZp032jSmczBbSu3h0hpvSlO7g0LM51beTeGA
|
||
f8nfPShK4eXS2PUUlF6YojKlFo2cQmXFwo+11Fo2QuuxwHfHS9GORXh3/PRp
|
||
IawUUzh4e3l9UNwbe7u0pmuncHBx/vbyoHDdvFHOKaP9upVTODu9+bG4m8Lz
|
||
ohCdXxk7LQDGsOjqmic9WVnlvBIaLuLEBQCAsUuh1d+EV0ZP4UxXspW6ws1c
|
||
SSeFLVfS0oOyEaqegpJ+8Z9p7ZNKFoU2thFe3Umc8+rHk2fHx9+Hj98df/ti
|
||
WhS4/+Ez3z9//iJ8/Pbr/vFvjr+ODxwfP8WPZ+OXk55U96pxcixLP6U1RZ6d
|
||
vpdlhzuAE6O9fO/hxtxKzfx7qZy3at55WTEDVQk/GXu7qM29O+BxhF1KP4WV
|
||
962bfvVVJbzwVpS30k5wwxNjl19Vpvxqk3VpPV9tLZW5WonleKV8PXZiIf16
|
||
uGwWmrjkS1Orcs0rn8LL2St4KWu5JM7AvfIreN01QsPbO2mtquTvXPrO9W1v
|
||
Q76X5Vh0ldog+Yk1zo1fmkYoDT39Z/hkoP7vXGA/8z7izuVK3CljRT2+k1Yt
|
||
VMlivIPIP6RH4c/ZoyB0BZfSknjqUsIPUperRthbpZdfhMB71rhvS6Vwpajk
|
||
uLXyDkV1925+FKrurIQTfhou09O0oStT13NR3n6RDWyvaO/ajXZSu84Nl3ze
|
||
1V6Nk6zzI7TOE9GKuaqVX8OFXBqvmCeZfv0S649T7l02SXJFkvxRSedtBCm3
|
||
QtW8kyvpTGdLCbOyNJ32X0p6tte2bxcmaIVxG6g33MS1F7oStlJ/k9WGHkn0
|
||
3mntvgwTtla3bxsLWUlLYjBurboT5YbK/JF/j6oc3khhtdJLuOSnWa6Iamlb
|
||
52rJQ36RrWyv8KuiGI/HIOYOh/FFcbNSDipTdg0usRGtA7+SZKNB9PSl8aAW
|
||
unKlaOWoUGh31UJJB7LG0wZL0QI6Ag7uV9JKcImNfFSUw2ml9oWxoLTrFgtV
|
||
Kqn9iAihtLem6krpwKn3UJqmFRrfo63hqoQvRFVZ6XiJjXEeSqu8KkWNs7sJ
|
||
kKDAs2+e8gbiq6YrVwUqHNpFaZqm00G5jYB34tcjYLvCyzFtoJwbFWvpQRtw
|
||
Si9rCVYupJWogNHjUF6WHvWbR1L4lWzAm6X0K2knTFyiS3TSWmvuVCUdCHDe
|
||
dvRqBdaIqhEtCbVfySKSzgF6U6ClrGQF3oDUYl5LWugIKSYtrXNeS1p1QceO
|
||
HtninSyNWzsvGzdhGWhUVdWyKJ7AWSA9brcoslPlzMLfCyt5CIfsBaVLZDLS
|
||
Yg2VbGuzlsi9QktPq22EFkvZEGPL2nQVGPTMUOCY4K5r23o9LldC6aI2S/T1
|
||
Ssdkn52NK6tQnO6j27OHqwVxFZCrrpWld2AWn8jgYsjgCcBrcy/vpB0h9Z0E
|
||
uVgY6x1YSYp0YcUS9yOrafF3yAGzxuEEou4ltowWBV+oRXkLQq+3Tg0KfV1P
|
||
Ng9qkiO/slJCaTT7jbifaVEcT2C2d4Er4aMrLYN0oLIZrEdpb6AWa2kdHF5L
|
||
Eg14fjQpimc4tOvsnVwjxeV7ZJ9eMmtIACwqBKE9CmwvhjhFEKM04Asc8DkO
|
||
ODgkQbescdigXHLFouU9GHL05XuPAUAF/YER9ACel1FiAHukIh4zfNMs9msZ
|
||
2Ktl8E1UNGkHDr4msf3miDgk6UzSivAkEu2VLusOOYW0wR1RcAQo/daNKHSC
|
||
SllZemPDIYiGByrp1FIjD+SdqDtBhCYiFD1hWddvCU6UYbcyXV3BwpQdnvwn
|
||
cCNto7SpzXLNa76Va1xc5eDg/N31zcGI/xcu3tLnq9P/end2dfoSP1+/nr15
|
||
czAq+EN84vr123dvXvaf+jdP3p6fn168xJeLg4u3NzD4Exycz/5ywHs+eHt5
|
||
c/b2YvbmAJQGnws70ghlac7kta2VaFSFQ/qUVs1J/8APJ5dw/AJ+/TWEdR8+
|
||
FPQZ47oPH5BsOqh2Xa/DV7+SaxBtKwWaJBB1XZSiVV7UyAoi3r0GJPjk76VV
|
||
+FB8Dq1gm1bFp9EK9tGq2KTV//0vEeufErXCl4+RqxiQC/aT61//ipT5eQp/
|
||
nJft8Ys/hT/ghgd/jDQb/JFotv2XrZeZiDv+tGOaRM3B3zcoPVzv7C+D75Hu
|
||
2R//+B+10hLGx9/9x58KlpGFqWtzj0fVS9uwSuocGvCVNd1yZTo/ZNq0KMhD
|
||
nBZT1K3R6KJyMhqZylqJbJwGjNLqBVk7aK3SpWpJMx2uyFU2doCTiPoI5aHl
|
||
uBG8cLdulFlIWQCrR0OakjX0CMhF8xJ9RP4ZVa3Voobeidh0v2n5yclCa1JL
|
||
NhEUceslNBReOS9bXggNbTo0P2jBlO5wMN6H61pp75RjE05KlIYQpEQrWdJP
|
||
aFbmAolrNLSESoxoLPk++JVS3ylrNNIZV++FR+Fkj/w0+kS4dGSdkz65EY7k
|
||
XdmeyPwXnoatvMClLzFi0GTzeUpPhmBhRXLxwOFe0Lc9TN5IAVApV+LL6HOi
|
||
53bECsnKeg1GT4oCkZXDl2QdMIwo12WtSnhlRbs6YmlZ4ufelwyCZsDK1kpH
|
||
Pn1P9GjrZcJA2lroaFeZJStxJyEia+UajK2kVXqJhO7IDy6VLbta2P4pJVEe
|
||
Xp/dvIFDCtjGSo/9So7fGNOGhZKLYmpohUdJQv1xv1Il2uUguOSQGQtN53CR
|
||
okUnR46gMZVarEkmrfwfWXoQUcoE+xFzuTAWJVl58OIWY5LFQpZ+UhSnJzdw
|
||
uAdziyuz69YbIiQa+XoNZHWRjLdS8+ErhbXBsRvQL4gaHCLxMk+zYjiMHAGE
|
||
OAPDMcD3Vijt3RF5+xs7mQBcS5zh11/3gIkfPqD0nlzC4S5ELuyID0JvFGgL
|
||
6CVzwNaiB+BxcRHxcbg4G4GBWjXKB19EulLU7FHYrpZusOqgO9AUwJK89i3K
|
||
7N3RTkyPdpfhXzPvJR5ZwpZwZ4xLkWYpa6GaoBrDev7FgUVEo5FpZ0x01H2O
|
||
/FHUHLXAoCsQyVjocS90vRaqRg0R8aqAX/H0iwBmNaaSmQRrkNaSygSjZaJN
|
||
a00rUApcVP0gwnFkpscYZwSl6BwfMteVpXRO3aWoyxuaF1facoiM+tBY1ArM
|
||
tq72eAB7xOoyASskDtGfnK/DimkRbZ2msFLgPpZWUuBWAMVV4FZEqahsR6w+
|
||
6SSGk4f6Y1IUCZ+5VkstwrSNdE4sJSysabZPubFJxRu7DmalAGao0qzRXH9A
|
||
vIGVqP1QHZi6BkQP6eg7KDtrs8OE3u5VCoJmWRC0aagrJZZWNBB0JobnFPxg
|
||
bB4HKAZRFB2DR2JsgFMkKY2SgyVoG1KA1EMmIeTAI7km56CI0dCkKH777TcQ
|
||
rlRqLKwv/jD+Pf/+UDzAjn+v353PLuDt5enV7Obt1fWuR8K/h40B/pp4/89A
|
||
FuANbhnGY3g1u4Rvf94xwD9gB7NXpxc3cHZxc3o1O0EnDd7M/nJ6tX8H/Rr+
|
||
8Mlf8vcfIrwKD3/8U/zyQ/7lJP/yEh52zP+HfJaPf9niwAMQkZ9Psy/HT6fZ
|
||
l/jLbg4+QIZy4xfRTi7kckK/kBqefOz97M8bXyh3sfv9SNWBIHzilz0CcPrf
|
||
pyfvMsYfnp7cHO1kf9gAula9X/AAJytZ3rYGTTM8pLQE/oDujvLwg5XiFmNx
|
||
fv+vSN9n0x15jZ/Djy+maZifN+b/B5yAy7dvzk7+Av8Mr97++fTqYnZxcrr3
|
||
DNAGZieX45ezV2M6tA9wYzvn4bo06OyheDvXWcozXbJNdBvv0x6/nkIPcwdc
|
||
O+7/mykM8xHo4v78DyPA2cWPV7Prm6t3Jzfvrvbvvd/AWfDW4AHzruyII+sl
|
||
IpKMDcJDn3H4wapqGajQE+C76QaEH3f//XRXpuXnTQIeH0/3JvW2decXFKHf
|
||
fvut+HUKTxZqOUbLxmmLfz/YiIz2GNCDD2xCQ3omGHXH9q5HJ2MuhRDQVR4Z
|
||
1Ma0MSZwcIjVCN8eTYCiMF7CWYg/EZTmYVWMVILXkkWxI9AhKycHQGZBIx8/
|
||
PRoFHyel2HjO50fs5na6knZpMlewyFOg/PBxXGCvN3hhDHk71CljikaLhF5z
|
||
9BwSk9AnJnnEZ0c0uw1qglf7Ik4Tsuz4xCuKMUlCeEqJPi0GlCGxUyBOnU5i
|
||
HVNNNODXPEueoON4EzylBXnab+K0Z8PQledbCV2hDujD1yx45ZGTm9nEJBZP
|
||
/x0Rn49CIdJR4B+/DwxoszMwz85AoPzxEXlzpwO0GSsjAjDuAqI8t0ouMIIj
|
||
gNptwNM9rs8OWDFAqIMTF7dBaOkT+Ons/PoUDnGu2oiq1xpKA6eLr/mgnPZA
|
||
gzvi08HvDoHf6OkxIExDRprSKdlbH4IWzR09HhniI/H0kau5MJ2umBfosWIY
|
||
u2b8ZCs+pawIhbExqBXE10CWOY1kOdR/8gSuZjfXcHglG+MlzG5SnIbTl7Lq
|
||
rLw+Kgp6qpILpTHVkCkQN0C6Oay0NFgh+qCP0VwswPnwYQJ5OAgS90jJDcx7
|
||
ta0VyomawDaG02tCdmtVUrToDceOtHsO0LKwj2LJsLG3sw6zBXjoLmaXRcHf
|
||
n02eJmznlUXnPS8DoNQVE5JhtyKZjUMc5SgxReRPYWapkSgHblLcWKFdCKs8
|
||
s5wmJBBCvi9XQi8lNBI/KMe4YjHItVBE7U0ILqu+IodSbWF71ydnNzdweE1J
|
||
ODjBX0jVLgmjAFpFK1Djh0woOQZHRcEvRl767Lke3VpwVIcjc3pPWK8WiFxO
|
||
AM4wrmoRMhoTplybJQXSNSr2bCNFQEQyDRWF5U6yDqQcuNJL3hKWmcHhRcg/
|
||
nqf8Y7BLCBOGA0lPDs8jJUYkIavbGcyizxJmGCQleTxr+uzhkIFN6iQOt+h0
|
||
GRONM0Y9OMUZHiiyITBJjiq9EXaNWB5aDhnzwpx7SsFkVWyi/0yOM111ztt1
|
||
X5wyhdmzGdHw/OSSKTGLwsLG9nD2bHbUAwX0KLEmKKFMns9PLo/omMlG2iXT
|
||
I0zYp+EoPKZTNkjGTgB+WqlagjaeVXJApcqQa+cUA9fgxS33icH5GlZquarV
|
||
ckVKfWDpCTigPKrLCkg20uQsv4rZgRYlL4PcsCU7Sxwcp1xkxBqyXH2qjtgN
|
||
DmR25RWOQxB/LZwjXuLeKEWssPKuGMPJ1dnN2cnszRQuTG/G4myZGSFI2pp5
|
||
LZt/KyBBVN7kdIDW4LOqaWRFThLjbZxHzSjEFU5WuVsqE4DXZ69eT+ESjzGq
|
||
SbT3COnQehwBwpivzYo5cO8MfYWCgm1CcNEA2Uma4/z05dm7cwbgid2E3RKG
|
||
S2MySIfZkFp6qTEzO6ecQWWkI0nCzW3vLe7iCXP5eAqP19f9+gTrWo8/FMV1
|
||
YsQ08QERwVAji+jWGVzTLAWeDKQ9XCM21sQ8yMamXaw3oOOSkyfLT2AyI4gV
|
||
qsftkgBUN1H/s8VktLMAGHirZhHRTaKaQp2Zjh6aZMJjk2XNqlIyA4vjt7Xw
|
||
dBRVshAFYA5A/tKpO1ET6MWygI/3FnYDlkVAcY5WIsOcB7gsoncJmc2ccIiI
|
||
LKGfcU8JRJ8UxRR+4iRSDuPm1BglzNFBKbQ2njMvyItOuRXMpb+XWGOQoEZc
|
||
/EIov8Ka5HUAtaULKGPbu+WI9tLTK8xGW7XwqHHmOBpS3ppGOVkhzQyFL70Q
|
||
mM479AdwwFQ00Ar0B7y0jlxxRTM6kKQkKTNRoRNgUayU3gklhxCJEFwJjXJM
|
||
lej0IAUAseOu9VCZe6SkFE0GIvfnkKsriD2oY6h4q6SMXi6RmBfaws/daCiQ
|
||
yVnj2mpKNyD9er8teY0umYTk0yDH8bhMiuKsaTElqRbwTifMFA/cO11Jz2my
|
||
wJ87Zepkure0EJ01qoxA6D3pDMz0VZz8w1o7mFPUKCkjim9QHIfUDGqWxk4l
|
||
PcOkH2afot6OGvQkaFBcMvnG+TEk9er6Q5efRs69+SG1B6c7x3M+Pd8SHTo8
|
||
aTGvGeYasrB3PCnTEOtmXmLdDO5m93x7Soo/fEhq+VlUy48UCrNmfvZ5mnmE
|
||
+IuqqQpnj5Y+33mAsL7ND3Kg7D9H8CEzsnnCh45WSvmg8GbnK2SUSYQo05Mg
|
||
gShIE0BDv1vXU8oxadkyAJLzAEiO+uW4IPIDceXyMKE0e5h6M1BQPdDCCuAk
|
||
pFFa+mtJCQvFLrKoxitTAhodVLkEXkhv1wWgO49nltI36PwqKigYel+a4oMN
|
||
X4Et+3tCT7KiyLwAkMt7KZNEyntBmBRKqK5Qr6O/VTVKB+AOM9gEc4R0tjY8
|
||
TYPdCWJNvhElqhLlKLFF43irlksZ8oaJar16Sioy04c74J2B2sbBeh2xI84A
|
||
V0otrDIDhKsXNBd01UC82E+CGrcbQwnI6xofUZezWMXIIhDJEDUibyclLdFL
|
||
8YqsSm5zekcuJTDhHv2I1kpRxaiQrS0anNQcohl2aQiAyMj8MY2JyfxH8I/e
|
||
j0lp6MBGRDNC9UK/1Z67DofCItTPUW3bzQaZVnselctmL0GKyYJSe76h1NDh
|
||
3lBoz2b9W3sU2U8rqbeSulhHwTndndlcLBmSk+VkBCJJJLpkatnZBBvoJVYW
|
||
9/AdYNGXCSYBk7+cDIbSGFspTQy10rW4X5JRTfEFG9WjEZVR5yquh2NT7Mma
|
||
DmU/xpC9qkoZajqFebdUyLvuGNDB4ZVY+BFcivfGHeEWECOSociDgSfCiTxX
|
||
knoJjShXaBVHZAdZTa3QMTNLqWXm1ZM49/ooD0hR2XtKqmDwWMfazm0fNqi3
|
||
fumU1P+lU4SSVZXiOq5eSrFGYIX1dvcSI2FZwZ3BM8PmJfapBHyixXOE5Uts
|
||
F/o1jNMayIlD1WKcqIc+tegjzkjP0UAHJMazRPWWAsezSnoEMjLQigMDK4Mz
|
||
MzQPAXD8qFZ/TLPxseMhtgPOEAFk8orqKRaTjbj0hbzlrQDOx8rvMDjWaqja
|
||
uI8prTx874uke4wyBfIZWUOpEEnDZ+mk+FKmijANKUU9vsGyGJa0lN087xnD
|
||
6ujFR9VR71SNMnztMb0kdmAAXKWFvwTAE8UiVLeg/Hc6BUW0p186nNFtK5A9
|
||
PhJmVJDgtEuKXsoE1FrpvAklbQyeyDtF7Q5UHMiRFxpwPjpY6lavQTWtsV6w
|
||
VTZ2lxGPgoJ74SoVqGQwgQPNymcscSEd9qFqTAlpPNq8OJQ5LVq3MrE+q9OV
|
||
yTQDzU3rysF7jBoSfM+B1+5zBdH3w6Mcl5ed3mAwLk5vTt5e/Mibso2sxuhc
|
||
KR+Va1QV4xTK4ZyVIW2KGtSKGkEpb+iFufIW1UReCdf7WYSDmEW/HuW4NLYj
|
||
8RjGwViRNoyEt82iWLNXiDLIDkJvu8LkgYeovOfo/mJcxiXnAkXz0Uj07Qba
|
||
QKFl6pXZoViCFxwdxAxyDuWxKGMduY4eIRQdHZu+JREFUlL+OpU+Pa6T9jCw
|
||
96AStRephm7TMXBUGv7FXKZBKcGejjlWUl9/VEmF50fZiJyl26eoZtnR7S0m
|
||
BXg7sqqs/NGd6rklakYM4rnbecB6yx7ztrDsBKaTZKgnBkpCrw1mfijFYixV
|
||
7GqqUmUI/cLswM6HiDAZdJ4gTMjmzyyy/YSmvrCrEXtqIceRfBpF4AwP1eNT
|
||
DI9gPKC0alI6C8M79jKDmpe1bDA+5B6oaNV8rjUppM1T00RGHIYTPFOYpaPC
|
||
nlvoOQuUHla7D1Qd12vTeFRYzarHU84w8K8U7LbcSfKwtFPEr3QLABJ2jmcw
|
||
6ntvWuqdGeWxlkh1zUEtzzEaQqSaouIJRIkcE2MkhUZYzd6r1m3UK4/Lg2Ll
|
||
zqZHtU9GDVQgWCApodMxCToUbrRlG+LQ1zAm9dNpUZaypcbCXLAU9RIklwlp
|
||
jW1KFBKzTmaOFrAT+X9UQ71iK5Em6zOlbOZDOIfgC28/TtLbnB0HN4XZn6O1
|
||
trtoM621VeS03XTNSuubjwd6+NIIThKo96hTlWcVkufc27qB+qFcCSmg2NMQ
|
||
7Vw0cX3jKKZnvRlLXU2KbUiKT8UAjRpUlQQbPMjdBt+OhB6RDNEh4Bv7ClCA
|
||
9C1rxnpgg8OewtD5qY7ZYLRU6MSJppV2zCCzxyO3jKpj920PW4zu72/48IFj
|
||
IUrW46jRcaTXrSyx+WsUwYRIGwoiODG+MvehizQ8DNxAu7RccDEi+J23GmHw
|
||
XzppVa/Rem+Mc+75VvO0OybQMVdMKoth25QS4+VsHwreRw54oEu/7Gp0WTip
|
||
0aPKQ9uRd/7Shhvur4nyMuR6zIESyJMFWWPu4BnFTh4fe6Q7u+wxQcnNa8rJ
|
||
DaXxiYovuF6VbDjI9TLfVvS4NiU37/qGeW2oxgBEZdrgcikNlolFnielvbki
|
||
5lFlNmTjY0yc7EDuc+FMYtaLZn/cSLY/yx/burIh02zfTjcvX7jeaDFlxfbt
|
||
xxVbD8nziCdc9/fJuVNGsup7sXaorFw3pzYgbAnA8dAShzWmk8lbCzDABrYU
|
||
+O+kJlcnFSkyJuySBY6t5/hj77mlw4BtvVwEwUUw3rQj7Mcq5aJDf6BzEg94
|
||
cpo4JkxZSTw8VMPX1/8N0Pe0rGHJT0BHBqEVBQMk8PPQAZaion1ACAraoAL4
|
||
E/NFmabDntDQ1cG9WiJU8hCZqoE+QnLTgtexXqG/xqOSCGHbXaxAjWcwy61T
|
||
BnMnAJ/BVGmINAfnc8hBoHGJB9rnZQJTVCgp/xuzpgHDW8msN02sSb1SACkI
|
||
7iKrGbMK3rSgCNhaMOwQLySQLvbBbGYv0D7q4LNnbnHMAn5aqFljBQRnaTki
|
||
9CZ13A168MOJUjqXXOW7qPWIWEjsDadvo6biUXX3O+WKXttKRia+BnH5rMBz
|
||
606XTM9tVXAHHy5dxRL03Hcbeo7LVoaa7myjkubxaJOESXK/JtfMylSMEBdK
|
||
trCvEIkIDMuSxuRAwHlDuXbE3M9PLgc/HGHnVy3z4GOrV48iwNTCSDBRWXZN
|
||
MHcRHctcwix5jG5PStZTvkUFQ8dvkxaWoQSE/Rx2tEJnWl5dShFff3pSRAKN
|
||
oNLRUY++1zVHrf2VJNEjVnoDsd9DUayLiTBL4ngq6opThfgLXQLSrnjWowLu
|
||
rUt+xcr+1NsWJj2XqCCya0aiI5gtmaBmrKOuujLWIA5qtvgOnUiIjeA0pFiV
|
||
X3+xFJvI2DfWsvNckMC856LV3Q5pT+VBUvXLhGPfR/ru6L0gEv2gGBjmM/39
|
||
J5zpt5lPeFqiJlXlXhhpy3VBwKNr2PvsfODHKKIJERaZXZ6lHJt7HEKiE4gC
|
||
sbsqLIvMYpEsSg3CSAHjYQi8NLpURInU9stL5TTtfJ2VLGT1R8mvCG7zVt46
|
||
L/mKgZzSZYflXo4NT0zN840DZP2wCsrc6xCNhPVkrQKhLFaSb+GUl6HS2GEK
|
||
N1iowbq2sQxaXo4V4Qqj9iVScfCzwiu3+txjT54Om1k/OwJBDYr6qF6HSbDf
|
||
GFEZ9kE35shYMIKV0hwiU+mCtMiC3fv8DFxldzaqxw6H4WLeFd6z44uFGNir
|
||
GBLku6/XCyWZTz/hmH5ymjx5QIyuhUtgoiTErpZwMPuuIuoeIpH9Fze8K6la
|
||
a9HwzQG7IJMMptfZ1nJz1J/ZPtcoqjtpvWK3Ttm+ipzOcMzqZxhhn/COnfvo
|
||
uym3CiU2witqm8/rsfOKQ0r7yroe32q8xeXd1RkXp+FFpx8+0JCvb24uQ8Xa
|
||
8fHTAVSSuoGyYJaDsew+EPaJYECHlPyyCu9vzXJZCYzm8lYED0ibYTVgzIkP
|
||
Eu55cju/bGHIhETYUEfwEUOdo7AZeC/HMSUiK0CK1bJaUtnlAlop7cbKEkga
|
||
hIUzWE7FAJ5SclRaFZ2ouhZzw4bnY2ea2EKmV/sBbXHY+wFLU3cQ35uiyoxx
|
||
0dPeQIz2ce735qWPU0H2vv7HePw3S7I/ZqXPpbf7bfR2lR09zRdBZJM30q9M
|
||
xfdkDc5odhfXdpF/vxXUBdGzDLVnYartimQ+oDbhdZhtrmnFcU94M82gR044
|
||
WVOJChcXc/Xr4JFKLq2oIq8isfMnpKZ5++oDhI4r1WAahC6Sg9gQRrX3JFJk
|
||
zzC1hn49NQllxUF9yX68bG+AJlKjJqVH8gpvFA7laDCEPHfxBt9ppHCdjfdT
|
||
ZPXCfWKE2YOKOm3iszK1hnAldYfWOnBZxt6DwJ1Nhm8xKlntsMiwZM6AJzvd
|
||
15x8EYOdc5VKhHs5/lLVurAxClyF2/Q277wiPIQuEg0Nt4Mr9kI1ecGtND7f
|
||
CAYwnhpaqR+Ry6amRfGwNfUDUAcNNmeHZx+Kh+l4PKb/TMN/i4c915fv2SY8
|
||
wPEIjo+x5z+UFsP+QbZz2fAAz0bw4hNfz+5deD6C46fwQMjpY69suVLwAN+M
|
||
4PuPv7qFf8ADfPvx17ZDLXiAr0fwXf8qtpB7MR/HK0xDF/keYYlt41ltNaVC
|
||
8CCsVOsS/LF5MSPdAcjXy81lbe6nm7ei5HXxQ65St3vWOb+zm77/fLfn9x38
|
||
3vn+3zP+XYZg9yyCYYqCWf4FZqKBk/iFf9usHtwQUEm8GHg3b19m14BFBu9j
|
||
BuuAw36I2REoV/RtygLz1dySoQgaSc0OG71JjfCFcox2zxlV3sGizb73QEQW
|
||
qtDvvuO1rWX+cFREeHJXATGlOAko3uRikQ1yegTzTtWVg66lQg6aPXGCJs2f
|
||
PzlKPTh7epsoRV/k9Zh9hWwYfltpbM3z8ijLTa1CMnjzBju67G6HQsjG+fEI
|
||
1Xm6kiBd71B4Q72W17LsSFtjObSq+trBm+3e1u2bLfliOiqbxBZNGqlA8xub
|
||
R6eDq8P+vOP6hmlW2bp5UdhW11jWwMUuViPqGIT12Ygs8RIbkHoQnVA4hF6w
|
||
ZkzFy9O8F+VtSIvL921tKGnauVSD0cOwdGNUf3tjp2P7eJ8mz64qu9y6XWK6
|
||
v1chF9+QIaHb0bQS9ZjimHEo4Ic7upw2Q3hoBxTj5H1uBAkO2go4nqZes9RD
|
||
sLNrDW8PHOYaw40gOccGXvtWmsdFj3OcF9MNSgpT9gZziN60LV+cnXFL6EHe
|
||
g9IdqQNx2NVLCYscdtm+6wbCvRpUzxJah4dd7XsqHAJDdotPQgiwfnFYsCjv
|
||
RMUFzV729a4BuAlB3KQotm7sideEUK6aC682E+Ib5W0Rw+sv8BSV/IX85c3T
|
||
T1Ii31OPbiqwKmCjbiuvuBptF1sFOGajrIp8e3a/sXEOE4Gb/nnE/8KtsNiN
|
||
RZq6SD4aARvozMT2a1ZFwiUtM8j8Flx8Qn4n1bASOoMxUN35eOvc2exitkPL
|
||
DdUZ4uL8ZH+U8WJ2ugmmeAKzMuIKPDGpSVYAhJreht7vWNEV6vt8vHhkRB2G
|
||
fNv59sUHLE0Y/Xf0/83j4s17yAZZFaR8+0vo/h/lDEb/d2gAAA==
|
||
|
||
-->
|
||
|
||
</rfc>
|
||
|