1090 lines
46 KiB
XML
1090 lines
46 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-consensus-00" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true">
|
||
<front>
|
||
<title abbrev="Agent Consensus">Multi-Agent Consensus and Capability Negotiation 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 35?>
|
||
|
||
<t>This document defines standardized protocols for multiple AI agents to
|
||
reach consensus on shared decisions and negotiate capabilities dynamically
|
||
during runtime collaboration. As autonomous agent systems increasingly
|
||
operate in multi-agent configurations, the need for formal agreement
|
||
mechanisms and capability discovery becomes critical. This specification
|
||
addresses the lack of consensus protocols and capability negotiation
|
||
standards identified in the gap analysis for AI agent infrastructure.</t>
|
||
|
||
|
||
|
||
</abstract>
|
||
|
||
|
||
|
||
</front>
|
||
|
||
<middle>
|
||
|
||
|
||
<?line 45?>
|
||
|
||
<section anchor="introduction"><name>Introduction</name>
|
||
|
||
<t>When multiple AI agents collaborate on shared tasks such as network
|
||
management, resource allocation, or policy enforcement, they must
|
||
frequently agree on joint decisions. Currently, no standardized protocol
|
||
exists for agents to propose actions, vote on alternatives, reach
|
||
quorum, or handle disagreements.</t>
|
||
|
||
<t>This document addresses Gap 3 (Multi-Agent Consensus) and Gap 10
|
||
(Capability Negotiation) from the gap analysis <xref target="I-D.nennemann-agent-gap-analysis"/>.
|
||
Gap 3 identifies the absence of formal consensus mechanisms for
|
||
multi-agent coordination, while Gap 10 highlights the lack of dynamic
|
||
capability negotiation during runtime collaboration.</t>
|
||
|
||
<t>The protocols defined here enable agents to:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Propose actions and gather votes from participating agents.</t>
|
||
<t>Reach agreement using multiple consensus mechanisms suited to
|
||
different operational contexts.</t>
|
||
<t>Advertise, discover, and negotiate capabilities dynamically.</t>
|
||
<t>Record consensus and negotiation outcomes in verifiable
|
||
evidence chains via the Execution Chain Trace (ECT)
|
||
framework <xref target="I-D.nennemann-wimse-ect"/>.</t>
|
||
</list></t>
|
||
|
||
<t>The human-in-the-loop override protocol defined in
|
||
<xref target="I-D.nennemann-agent-dag-hitl-safety"/> serves as the ultimate
|
||
escalation path when consensus cannot be reached or when decisions
|
||
exceed agent authority.</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 throughout this document:</t>
|
||
|
||
<dl>
|
||
<dt>Consensus Round:</dt>
|
||
<dd>
|
||
<t>A bounded period during which agents exchange proposals and votes
|
||
to reach agreement on a specific decision.</t>
|
||
</dd>
|
||
<dt>Quorum:</dt>
|
||
<dd>
|
||
<t>The minimum number of participating agents required for a consensus
|
||
round to produce a valid outcome.</t>
|
||
</dd>
|
||
<dt>Proposal:</dt>
|
||
<dd>
|
||
<t>A structured message submitted by an agent that describes a
|
||
candidate action or decision for group consideration.</t>
|
||
</dd>
|
||
<dt>Vote:</dt>
|
||
<dd>
|
||
<t>A response to a proposal indicating approval, rejection, or
|
||
abstention, optionally accompanied by a rationale.</t>
|
||
</dd>
|
||
<dt>Leader Agent:</dt>
|
||
<dd>
|
||
<t>An agent designated as the coordinator for a consensus round,
|
||
responsible for collecting votes and declaring outcomes.</t>
|
||
</dd>
|
||
<dt>Capability Advertisement:</dt>
|
||
<dd>
|
||
<t>A structured declaration by an agent of the capabilities it offers
|
||
to other agents in a collaboration.</t>
|
||
</dd>
|
||
<dt>Capability Offer:</dt>
|
||
<dd>
|
||
<t>A message proposing the use of a specific capability under
|
||
defined terms during a negotiation session.</t>
|
||
</dd>
|
||
<dt>Capability Acceptance:</dt>
|
||
<dd>
|
||
<t>A binding confirmation that an agent agrees to the terms of a
|
||
capability offer.</t>
|
||
</dd>
|
||
<dt>Negotiation Session:</dt>
|
||
<dd>
|
||
<t>A bounded interaction between two or more agents for the purpose
|
||
of agreeing on capability usage terms.</t>
|
||
</dd>
|
||
</dl>
|
||
|
||
</section>
|
||
<section anchor="consensus-protocols"><name>Consensus Protocols</name>
|
||
|
||
<section anchor="consensus-model-overview"><name>Consensus Model Overview</name>
|
||
|
||
<t>The consensus protocol follows a three-phase commit model: propose,
|
||
vote, and commit. The following diagram illustrates the message flow
|
||
for a typical consensus round.</t>
|
||
|
||
<figure title="Consensus Round Message Flow" anchor="fig-consensus-flow"><artwork type="ascii-art"><![CDATA[
|
||
Agent A Leader Agent B Agent C
|
||
| | | |
|
||
|--- Propose ---->| | |
|
||
| |-- Vote Req --->| |
|
||
| |-- Vote Req ------------------> |
|
||
| | | |
|
||
| |<-- Vote -------| |
|
||
| |<-- Vote ---------------------- |
|
||
| | | |
|
||
| |--- Tally & Decide ----------> |
|
||
|<-- Commit ------| | |
|
||
| |-- Commit ----->| |
|
||
| |-- Commit -------------------> |
|
||
| | | |
|
||
]]></artwork></figure>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t><strong>Propose</strong>: An agent submits a proposal to the leader agent.</t>
|
||
<t><strong>Vote</strong>: The leader distributes the proposal to all participants
|
||
and collects votes within the timeout window.</t>
|
||
<t><strong>Commit/Abort</strong>: The leader evaluates votes against the quorum
|
||
and consensus mechanism rules, then issues a commit or abort
|
||
signal to all participants.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="consensus-mechanisms"><name>Consensus Mechanisms</name>
|
||
|
||
<t>This specification defines four consensus mechanisms. Implementations
|
||
<bcp14>MUST</bcp14> support simple majority voting and <bcp14>SHOULD</bcp14> support at least one
|
||
additional mechanism.</t>
|
||
|
||
<section anchor="simple-majority-voting"><name>Simple Majority Voting</name>
|
||
|
||
<t>A proposal is accepted if more than half of the votes received are
|
||
approvals. Abstentions do not count toward the total.</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Quorum: A minimum of ceil(N/2) votes must be received, where N
|
||
is the number of eligible voters.</t>
|
||
<t>Ties result in rejection of the proposal.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="weighted-consensus"><name>Weighted Consensus</name>
|
||
|
||
<t>Each agent is assigned a weight reflecting its trust score, domain
|
||
expertise, or capability level. A proposal is accepted if the sum
|
||
of approval weights exceeds a configured threshold (default: 50%
|
||
of total weight).</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Weights <bcp14>MUST</bcp14> be distributed and agreed upon before the consensus
|
||
round begins.</t>
|
||
<t>Weight assignments <bcp14>SHOULD</bcp14> be recorded in the ECT for
|
||
auditability.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="leader-based-consensus"><name>Leader-Based Consensus</name>
|
||
|
||
<t>A designated leader agent makes the final decision after soliciting
|
||
input from participants. Participant votes serve as advisory input
|
||
rather than binding decisions.</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>The leader <bcp14>MUST</bcp14> provide a rationale when overriding participant
|
||
recommendations.</t>
|
||
<t>Leader designation <bcp14>SHOULD</bcp14> rotate or be determined by a
|
||
higher-level policy.</t>
|
||
<t>This mechanism is appropriate for time-critical decisions where
|
||
full consensus would introduce unacceptable delay.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="optimistic-consensus"><name>Optimistic Consensus</name>
|
||
|
||
<t>A proposal is considered accepted unless an objection is raised
|
||
within the timeout window. This mechanism minimizes communication
|
||
overhead for routine decisions.</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Any single objection blocks the proposal.</t>
|
||
<t>The objecting agent <bcp14>MUST</bcp14> provide a rationale.</t>
|
||
<t>Optimistic consensus <bcp14>SHOULD</bcp14> only be used for low-risk,
|
||
reversible decisions.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="consensus-message-format"><name>Consensus Message Format</name>
|
||
|
||
<section anchor="proposal-message-structure"><name>Proposal Message Structure</name>
|
||
|
||
<t>A proposal message <bcp14>MUST</bcp14> contain the following fields:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t><strong>proposal_id</strong>: A globally unique identifier for the proposal
|
||
(UUID format).</t>
|
||
<t><strong>proposer</strong>: The identity of the proposing agent.</t>
|
||
<t><strong>consensus_round_id</strong>: Identifier for the consensus round.</t>
|
||
<t><strong>mechanism</strong>: The consensus mechanism to use (one of "majority",
|
||
"weighted", "leader", "optimistic").</t>
|
||
<t><strong>subject</strong>: A human-readable summary of the proposal.</t>
|
||
<t><strong>action</strong>: A structured description of the proposed action.</t>
|
||
<t><strong>timeout</strong>: The deadline for vote collection (as an absolute
|
||
timestamp per <xref target="RFC9110"/> Section 5.6.7).</t>
|
||
<t><strong>quorum</strong>: The minimum number of votes required.</t>
|
||
<t><strong>participants</strong>: List of agent identifiers eligible to vote.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="vote-message-structure"><name>Vote Message Structure</name>
|
||
|
||
<t>A vote message <bcp14>MUST</bcp14> contain the following fields:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t><strong>proposal_id</strong>: The identifier of the proposal being voted on.</t>
|
||
<t><strong>voter</strong>: The identity of the voting agent.</t>
|
||
<t><strong>decision</strong>: One of "approve", "reject", or "abstain".</t>
|
||
<t><strong>rationale</strong>: A human-readable explanation for the vote
|
||
(<bcp14>REQUIRED</bcp14> for "reject", <bcp14>OPTIONAL</bcp14> for others).</t>
|
||
<t><strong>timestamp</strong>: The time the vote was cast.</t>
|
||
<t><strong>signature</strong>: A JWS <xref target="RFC7515"/> signature over the vote content
|
||
for non-repudiation.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="commit-and-abort-signals"><name>Commit and Abort Signals</name>
|
||
|
||
<t>After vote collection, the leader issues either a commit or abort
|
||
signal:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t><strong>Commit</strong>: Indicates the proposal was accepted. All participants
|
||
<bcp14>MUST</bcp14> execute the agreed action.</t>
|
||
<t><strong>Abort</strong>: Indicates the proposal was rejected. Participants <bcp14>MUST
|
||
NOT</bcp14> execute the proposed action.</t>
|
||
</list></t>
|
||
|
||
<t>Both signals <bcp14>MUST</bcp14> include the proposal_id, the final tally, and a
|
||
JWS signature from the leader.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="quorum-and-timeout-rules"><name>Quorum and Timeout Rules</name>
|
||
|
||
<section anchor="quorum-calculation"><name>Quorum Calculation</name>
|
||
|
||
<t>The quorum for a consensus round is determined by the consensus
|
||
mechanism in use:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t><strong>Simple majority</strong>: ceil(N/2) where N is the number of
|
||
eligible voters.</t>
|
||
<t><strong>Weighted</strong>: Agents representing at least 50% of total weight
|
||
must participate.</t>
|
||
<t><strong>Leader-based</strong>: No quorum required; leader decides
|
||
independently.</t>
|
||
<t><strong>Optimistic</strong>: All eligible agents are considered participants;
|
||
silence counts as approval.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="timeout-semantics-and-fallback-behavior"><name>Timeout Semantics and Fallback Behavior</name>
|
||
|
||
<t>Each consensus round <bcp14>MUST</bcp14> specify a timeout. If quorum is not
|
||
reached before the timeout:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>The leader <bcp14>MUST</bcp14> issue an abort signal.</t>
|
||
<t>The proposing agent <bcp14>MAY</bcp14> re-submit the proposal with a longer
|
||
timeout or reduced quorum.</t>
|
||
<t>If the decision is time-critical, the leader <bcp14>MAY</bcp14> escalate to
|
||
a human operator via the override protocol defined in
|
||
<xref target="I-D.nennemann-agent-dag-hitl-safety"/>.</t>
|
||
</list></t>
|
||
|
||
<t>Implementations <bcp14>SHOULD</bcp14> use exponential backoff for re-submissions
|
||
with a maximum retry count of 3.</t>
|
||
|
||
</section>
|
||
<section anchor="split-brain-prevention"><name>Split-Brain Prevention</name>
|
||
|
||
<t>In distributed deployments where network partitions may occur:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>A consensus round is valid only if the leader can verify
|
||
connectivity to a majority of participants.</t>
|
||
<t>If a partition is detected, all in-progress consensus rounds
|
||
<bcp14>MUST</bcp14> be suspended until connectivity is restored.</t>
|
||
<t>Agents <bcp14>MUST NOT</bcp14> accept commit signals from multiple leaders
|
||
for the same consensus round.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="conflict-resolution"><name>Conflict Resolution</name>
|
||
|
||
<section anchor="priority-based-resolution"><name>Priority-Based Resolution</name>
|
||
|
||
<t>When multiple competing proposals address the same resource or
|
||
decision:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Proposals are ranked by a priority score derived from the
|
||
urgency of the decision, the authority level of the proposer,
|
||
and the specificity of the proposed action.</t>
|
||
<t>Higher-priority proposals are evaluated first.</t>
|
||
<t>Lower-priority proposals that conflict with an accepted
|
||
higher-priority proposal are automatically rejected.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="escalation-to-human-operator"><name>Escalation to Human Operator</name>
|
||
|
||
<t>If consensus cannot be reached after the maximum number of retries,
|
||
or if agents are deadlocked:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>The leader <bcp14>MUST</bcp14> escalate to a human operator using the override
|
||
protocol defined in <xref target="I-D.nennemann-agent-dag-hitl-safety"/>.</t>
|
||
<t>The escalation message <bcp14>MUST</bcp14> include the proposal, all votes
|
||
received, and the reason for escalation.</t>
|
||
<t>The human operator's decision is binding and <bcp14>MUST</bcp14> be recorded
|
||
in the ECT.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="deadlock-detection-and-breaking"><name>Deadlock Detection and Breaking</name>
|
||
|
||
<t>A deadlock exists when:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Two or more proposals mutually block each other (circular
|
||
dependency).</t>
|
||
<t>A consensus round cannot reach quorum due to persistent
|
||
abstentions or non-responsive agents.</t>
|
||
</list></t>
|
||
|
||
<t>Deadlock breaking strategies:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t><strong>Timeout-based</strong>: The oldest proposal takes precedence.</t>
|
||
<t><strong>Random selection</strong>: A verifiable random function selects
|
||
the winning proposal.</t>
|
||
<t><strong>Escalation</strong>: The deadlock is escalated to a human operator.</t>
|
||
</list></t>
|
||
|
||
<t>The leader <bcp14>MUST</bcp14> detect deadlocks within two consecutive failed
|
||
consensus rounds on related proposals.</t>
|
||
|
||
</section>
|
||
</section>
|
||
</section>
|
||
<section anchor="capability-negotiation"><name>Capability Negotiation</name>
|
||
|
||
<section anchor="capability-advertisement-format"><name>Capability Advertisement Format</name>
|
||
|
||
<section anchor="extending-agent-discovery-with-capability-descriptors"><name>Extending Agent Discovery with Capability Descriptors</name>
|
||
|
||
<t>Agents <bcp14>MUST</bcp14> advertise their capabilities using a structured
|
||
descriptor format. Capability advertisements extend the agent
|
||
discovery mechanism and <bcp14>SHOULD</bcp14> be published during agent
|
||
registration.</t>
|
||
|
||
<t>A capability descriptor <bcp14>MUST</bcp14> include:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t><strong>agent_id</strong>: The identity of the advertising agent.</t>
|
||
<t><strong>capabilities</strong>: An array of capability objects, each containing:
|
||
<list style="symbols">
|
||
<t><strong>type</strong>: The capability type from the capability registry
|
||
(see <xref target="capability-registry"/>).</t>
|
||
<t><strong>version</strong>: The version of the capability implementation.</t>
|
||
<t><strong>parameters</strong>: Capability-specific configuration parameters.</t>
|
||
<t><strong>constraints</strong>: Limitations on capability usage (e.g., rate
|
||
limits, maximum payload size).</t>
|
||
<t><strong>availability</strong>: Current availability status ("available",
|
||
"busy", "degraded", "unavailable").</t>
|
||
</list></t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="capability-categories"><name>Capability Categories</name>
|
||
|
||
<t>Capabilities are organized into the following categories:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t><strong>Compute</strong>: Processing power, model inference, data
|
||
transformation.</t>
|
||
<t><strong>Knowledge</strong>: Domain expertise, access to knowledge bases,
|
||
training data coverage.</t>
|
||
<t><strong>Tool Access</strong>: Integration with external tools, APIs, or
|
||
services.</t>
|
||
<t><strong>Authorization Scope</strong>: Permissions and access levels the agent
|
||
holds in various systems.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="version-and-compatibility-metadata"><name>Version and Compatibility Metadata</name>
|
||
|
||
<t>Each capability advertisement <bcp14>MUST</bcp14> include version information
|
||
to enable compatibility checking:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t><strong>min_version</strong>: The minimum protocol version supported.</t>
|
||
<t><strong>max_version</strong>: The maximum protocol version supported.</t>
|
||
<t><strong>deprecated_versions</strong>: A list of versions that are supported
|
||
but deprecated.</t>
|
||
</list></t>
|
||
|
||
<t>Agents <bcp14>MUST</bcp14> negotiate a mutually supported version before
|
||
initiating capability usage.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="dynamic-negotiation-protocol"><name>Dynamic Negotiation Protocol</name>
|
||
|
||
<section anchor="negotiation-initiation-and-session-management"><name>Negotiation Initiation and Session Management</name>
|
||
|
||
<t>A negotiation session is initiated when an agent requires a
|
||
capability that it does not possess but has identified in another
|
||
agent's advertisement.</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>The initiating agent sends a <strong>Negotiation Request</strong> specifying
|
||
the desired capability type and parameters.</t>
|
||
<t>The target agent responds with a <strong>Negotiation Response</strong>
|
||
indicating willingness to negotiate.</t>
|
||
<t>A <strong>session_id</strong> is established for tracking the negotiation.</t>
|
||
</list></t>
|
||
|
||
<t>Sessions have a configurable timeout (default: 60 seconds) and
|
||
<bcp14>MUST</bcp14> be explicitly closed by either party.</t>
|
||
|
||
</section>
|
||
<section anchor="offercounter-offer-exchange"><name>Offer/Counter-Offer Exchange</name>
|
||
|
||
<t>Once a session is established:</t>
|
||
|
||
<t><list style="numbers" type="1">
|
||
<t>The initiating agent sends a <strong>Capability Offer</strong> specifying
|
||
the desired terms of use (duration, rate limits, data handling
|
||
requirements).</t>
|
||
<t>The target agent may respond with:
|
||
<list style="symbols">
|
||
<t><strong>Accept</strong>: Agreement to the offered terms.</t>
|
||
<t><strong>Counter-Offer</strong>: Modified terms for the initiator to
|
||
consider.</t>
|
||
<t><strong>Reject</strong>: Refusal to provide the capability, with a
|
||
rationale.</t>
|
||
</list></t>
|
||
<t>Counter-offers may continue for a maximum of 5 rounds before
|
||
the negotiation <bcp14>MUST</bcp14> be concluded or abandoned.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="acceptance-and-binding"><name>Acceptance and Binding</name>
|
||
|
||
<t>When both parties agree on terms:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>A <strong>Capability Agreement</strong> is created containing the final terms,
|
||
signed by both parties using JWS <xref target="RFC7515"/>.</t>
|
||
<t>The agreement includes a unique <strong>agreement_id</strong>, the agreed
|
||
capability parameters, duration, and any usage constraints.</t>
|
||
<t>Both agents <bcp14>MUST</bcp14> honor the agreement until its expiration or
|
||
explicit revocation.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="re-negotiation-during-runtime"><name>Re-Negotiation During Runtime</name>
|
||
|
||
<t>Either party <bcp14>MAY</bcp14> initiate re-negotiation of an active agreement
|
||
when:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Resource availability changes.</t>
|
||
<t>New constraints are imposed by external factors.</t>
|
||
<t>The original terms are no longer adequate.</t>
|
||
</list></t>
|
||
|
||
<t>Re-negotiation follows the same offer/counter-offer protocol but
|
||
references the existing agreement_id.</t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="capability-registry"><name>Capability Registry</name>
|
||
|
||
<section anchor="well-known-capability-types"><name>Well-Known Capability Types</name>
|
||
|
||
<t>The following capability types are defined as initial entries in
|
||
the capability registry:</t>
|
||
|
||
<texttable title="Well-Known Capability Types" anchor="tab-capability-types">
|
||
<ttcol align='left'>Type ID</ttcol>
|
||
<ttcol align='left'>Category</ttcol>
|
||
<ttcol align='left'>Description</ttcol>
|
||
<c>compute.inference</c>
|
||
<c>Compute</c>
|
||
<c>Model inference execution</c>
|
||
<c>compute.transform</c>
|
||
<c>Compute</c>
|
||
<c>Data transformation and processing</c>
|
||
<c>knowledge.domain</c>
|
||
<c>Knowledge</c>
|
||
<c>Domain-specific expertise</c>
|
||
<c>knowledge.retrieval</c>
|
||
<c>Knowledge</c>
|
||
<c>Information retrieval from knowledge bases</c>
|
||
<c>tool.api</c>
|
||
<c>Tool Access</c>
|
||
<c>External API integration</c>
|
||
<c>tool.execution</c>
|
||
<c>Tool Access</c>
|
||
<c>Tool or script execution</c>
|
||
<c>authz.delegate</c>
|
||
<c>Authorization</c>
|
||
<c>Delegated authorization scope</c>
|
||
<c>authz.verify</c>
|
||
<c>Authorization</c>
|
||
<c>Credential and permission verification</c>
|
||
</texttable>
|
||
|
||
</section>
|
||
<section anchor="extension-mechanism-for-custom-capabilities"><name>Extension Mechanism for Custom Capabilities</name>
|
||
|
||
<t>Organizations <bcp14>MAY</bcp14> define custom capability types using a reverse
|
||
domain name prefix (e.g., "com.example.custom-capability"). Custom
|
||
capability types:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t><bcp14>MUST NOT</bcp14> conflict with well-known capability type identifiers.</t>
|
||
<t><bcp14>SHOULD</bcp14> be registered with IANA for interoperability when intended
|
||
for broad use.</t>
|
||
<t><bcp14>MUST</bcp14> include a human-readable description and a machine-readable
|
||
schema for parameters.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
</section>
|
||
<section anchor="ect-integration"><name>ECT Integration</name>
|
||
|
||
<t>Consensus and capability negotiation events <bcp14>MUST</bcp14> be recorded in the
|
||
Execution Chain Trace (ECT) framework defined in
|
||
<xref target="I-D.nennemann-wimse-ect"/> to provide a verifiable audit trail.</t>
|
||
|
||
<section anchor="consensus-evidence-in-ect-nodes"><name>Consensus Evidence in ECT Nodes</name>
|
||
|
||
<t>The following exec_act values are defined for consensus operations:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t><strong>consensus_propose</strong>: Records the submission of a proposal.
|
||
The ECT node <bcp14>MUST</bcp14> include the proposal_id, proposer identity,
|
||
and proposal summary.</t>
|
||
<t><strong>consensus_vote</strong>: Records a vote cast by an agent. The ECT
|
||
node <bcp14>MUST</bcp14> include the proposal_id, voter identity, decision,
|
||
and rationale (if provided).</t>
|
||
<t><strong>consensus_commit</strong>: Records the outcome of a consensus round.
|
||
The ECT node <bcp14>MUST</bcp14> include the proposal_id, final tally,
|
||
outcome (commit or abort), and the leader's signature.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="capability-negotiation-records-in-ect"><name>Capability Negotiation Records in ECT</name>
|
||
|
||
<t>Capability negotiation events are recorded using the ECT ext
|
||
(extension) claims mechanism:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>The <strong>ext</strong> claim <bcp14>MUST</bcp14> include a "capability_negotiation" object
|
||
containing the session_id, capability type, and negotiation
|
||
outcome.</t>
|
||
<t>Agreement creation and revocation events <bcp14>MUST</bcp14> each produce an
|
||
ECT node with the agreement_id and relevant terms.</t>
|
||
<t>Re-negotiation events <bcp14>MUST</bcp14> reference the original agreement_id
|
||
and include both the previous and updated terms.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="security-considerations"><name>Security Considerations</name>
|
||
|
||
<section anchor="sybil-resistance"><name>Sybil Resistance</name>
|
||
|
||
<t>To prevent an attacker from creating multiple fake agent identities
|
||
to influence consensus outcomes:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Agents <bcp14>MUST</bcp14> authenticate using verifiable credentials bound to
|
||
their operational identity.</t>
|
||
<t>The leader <bcp14>MUST</bcp14> verify agent identities before accepting votes.</t>
|
||
<t>Consensus mechanisms <bcp14>SHOULD</bcp14> incorporate identity verification
|
||
scores that penalize newly registered or unverified agents.</t>
|
||
<t>Rate limiting on agent registration prevents rapid creation of
|
||
sybil identities.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="byzantine-fault-tolerance-considerations"><name>Byzantine Fault Tolerance Considerations</name>
|
||
|
||
<t>The consensus mechanisms defined in this document do not provide
|
||
full Byzantine fault tolerance (BFT). Deployments requiring BFT
|
||
guarantees <bcp14>SHOULD</bcp14>:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Use weighted consensus with trust scores that reflect agent
|
||
reliability history.</t>
|
||
<t>Implement cross-validation of votes through independent
|
||
verification channels.</t>
|
||
<t>Set quorum thresholds to at least 2f+1 where f is the maximum
|
||
number of potentially faulty agents.</t>
|
||
<t>Consider established BFT protocols (e.g., PBFT) as an
|
||
alternative consensus mechanism for high-security environments.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="capability-spoofing"><name>Capability Spoofing</name>
|
||
|
||
<t>Agents <bcp14>MUST NOT</bcp14> advertise capabilities they do not possess.
|
||
Mitigations include:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Capability advertisements <bcp14>MUST</bcp14> be signed using the agent's
|
||
verified credentials.</t>
|
||
<t>Consumers <bcp14>SHOULD</bcp14> validate capability claims through test
|
||
invocations before relying on them for critical operations.</t>
|
||
<t>Agents that fail to deliver advertised capabilities <bcp14>MUST</bcp14> have
|
||
their trust scores reduced.</t>
|
||
<t>Repeated capability spoofing <bcp14>SHOULD</bcp14> result in exclusion from
|
||
future consensus rounds and negotiation sessions.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
<section anchor="coercion-and-collusion-detection"><name>Coercion and Collusion Detection</name>
|
||
|
||
<t>To detect coordinated manipulation of consensus outcomes:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>Vote patterns <bcp14>SHOULD</bcp14> be analyzed for statistical anomalies
|
||
(e.g., identical rationales, synchronized timing).</t>
|
||
<t>Agents <bcp14>SHOULD</bcp14> be required to submit votes independently without
|
||
knowledge of other agents' votes until the tally is complete
|
||
(sealed-bid voting).</t>
|
||
<t>The ECT audit trail enables post-hoc analysis of voting patterns
|
||
to identify potential collusion.</t>
|
||
<t>Human operators <bcp14>SHOULD</bcp14> be notified when anomalous voting patterns
|
||
are detected.</t>
|
||
</list></t>
|
||
|
||
</section>
|
||
</section>
|
||
<section anchor="iana-considerations"><name>IANA Considerations</name>
|
||
|
||
<section anchor="consensus-execact-values"><name>Consensus exec_act Values</name>
|
||
|
||
<t>This document requests registration of the following exec_act
|
||
values in the ECT exec_act registry:</t>
|
||
|
||
<texttable title="Consensus exec_act Values" anchor="tab-exec-act">
|
||
<ttcol align='left'>Value</ttcol>
|
||
<ttcol align='left'>Description</ttcol>
|
||
<ttcol align='left'>Reference</ttcol>
|
||
<c>consensus_propose</c>
|
||
<c>Agent submits a consensus proposal</c>
|
||
<c>This document</c>
|
||
<c>consensus_vote</c>
|
||
<c>Agent casts a vote on a proposal</c>
|
||
<c>This document</c>
|
||
<c>consensus_commit</c>
|
||
<c>Leader commits or aborts a consensus round</c>
|
||
<c>This document</c>
|
||
</texttable>
|
||
|
||
</section>
|
||
<section anchor="capability-type-registry"><name>Capability Type Registry</name>
|
||
|
||
<t>This document requests IANA to create a new "Agent Capability
|
||
Types" registry with the following initial entries as defined in
|
||
<xref target="tab-capability-types"/>.</t>
|
||
|
||
<t>New entries in this registry require Specification Required
|
||
(per <xref target="RFC8126"/>) and <bcp14>MUST</bcp14> include:</t>
|
||
|
||
<t><list style="symbols">
|
||
<t>A unique type identifier.</t>
|
||
<t>The capability category.</t>
|
||
<t>A human-readable description.</t>
|
||
<t>A reference to the defining specification.</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="RFC8126">
|
||
<front>
|
||
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
|
||
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
|
||
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
|
||
<author fullname="T. Narten" initials="T." surname="Narten"/>
|
||
<date month="June" year="2017"/>
|
||
<abstract>
|
||
<t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
|
||
<t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
|
||
<t>This is the third edition of this document; it obsoletes RFC 5226.</t>
|
||
</abstract>
|
||
</front>
|
||
<seriesInfo name="BCP" value="26"/>
|
||
<seriesInfo name="RFC" value="8126"/>
|
||
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
|
||
</reference>
|
||
|
||
<reference anchor="I-D.nennemann-agent-gap-analysis" target="https://datatracker.ietf.org/doc/draft-nennemann-agent-gap-analysis/">
|
||
<front>
|
||
<title>Gap Analysis for Autonomous Agent Protocols</title>
|
||
<author >
|
||
<organization></organization>
|
||
</author>
|
||
<date year="n.d."/>
|
||
</front>
|
||
</reference>
|
||
|
||
|
||
</references>
|
||
|
||
</references>
|
||
|
||
|
||
<?line 608?>
|
||
|
||
<section numbered="false" anchor="acknowledgments"><name>Acknowledgments</name>
|
||
|
||
<t>The author thanks the contributors to the NMOP working group
|
||
discussions on AI agent orchestration and multi-agent coordination
|
||
challenges.</t>
|
||
|
||
</section>
|
||
|
||
|
||
</back>
|
||
|
||
<!-- ##markdown-source:
|
||
H4sIAAAAAAAAA7V8e3MkN3Ln//gUMBX2zvDYPRpptbum12tzyJGXtuZhDrWK
|
||
jYsLBboquxvLaqAEoMjpeeiz3Ge5T3aRD6BQ1T1jrfduIhRqdhdeiUTmL3+Z
|
||
qMVioZJNHZzrkxdDl+ziYgMu6UvvIrg4RG1cqy9Nb1a2s2mvX8LGJ2uS9U6/
|
||
Dj75xnfxRJnVKsD9uT6ZNT9RjUmw8WF/rmNqVesbZ3Zwrttg1mnhwDnYGecW
|
||
Btstmtxu8eWXygQw5/rk1es3J+rBh7tN8EN/rk9evnj1+kTFYbWzMVrv0r6H
|
||
c339/PZbdX+uv1bKDGnrw7nSeqHXQ9fxiJfbYGOyxumXeVSltdY+bIyz72hJ
|
||
5/ratdCDa3EVNxDBhGYLgR6EnbHdubaQ1v9aJr5sQSnnw84kew845s23l189
|
||
ffqP8vF3T3/7a/n422/Kt7/95uk38vEfnz79Ej9eL66Wozge7C7CApp0TkPn
|
||
LXr+FpqBZH/pXYK3Sd/6O3BRr33QVzamYFdDglbTNthG/+DD3brzD/GE+zFh
|
||
A+lcb1Pq4/mTJ61JJgXT3EFY4rqWPmyetL55Mt+eMp8nB1PlnWvNZrG1qVtE
|
||
s4a0n067KAVN+bXvbLPnmZ/rq4t/01fQwYZ16sGmrf7jsDNOv7qHEGwLf+PU
|
||
j87viVLWrWfb9runX/3mcCu4/cb0C+NMt482Thf3b6bXF/IL7cPFkLzzOz9E
|
||
3ob6nPw/WEk9kydKLRYLbVYRO0hK3W5t1K1vhh0O3MLaOog6JuNaE1r7Dlrd
|
||
59nQZHd46PsO9MW1pv6jTl4FMM1Wl9OovdNxawK0uoXG4qFjw+DEGoBusomw
|
||
EHW7d2ZnG9N1e9UOwbqNDoNLdge68V1nVj7Qbi/1RdRmFBdNQMd9TLCL2rom
|
||
gInWbbq98j0EHMc6njILA6e4tpuBu4tnOm1BO4CW1kb722mzCQAoD7WDZmuc
|
||
jTuefTOatdbGxt9D2OsVNH4HUTfBJlzCUpNMYw+NXduGBlKmbQPECJEG7Exz
|
||
p/26ktco49k4bjSfKu9K1BbNjV1baHF92OXG9NpMlEq2R1u3DiamMDRpCLBk
|
||
BdjZtu1AqS/0tUvBt0NDI6gftuCObfG4C1DtbTLxLuo4NFttonaQ0OqqnXFm
|
||
Q/I70wGiH0ID2nSdZ1mcaR90z0ca8Eg18mzawl7vhpjUOsBPA7jU7XkvcMi/
|
||
eEsKKtq01JdDCPTMmXb+uMYqeGtjYnkUXcVfex9Bm0Z04N7zqkyXIDg64BGn
|
||
bpqt+mnwYdjRnLfGtR3gzhcFicv5CRo3Go/51/rRUSf5mLYZn3j6pXp03Fs+
|
||
1uvgd4eb+/79f2VuPn5cKh696AnrnVlFcA2g6omqjxpYqfraBzU9Mz601snu
|
||
PWxtBzJ3vbWbbWc32zRVbDnP6rgi688ecZQoVAeCbVKrtxBAgzOrDsbNPFdq
|
||
geay3lCS7cakLQTa2siC7E1ItrG9STg297BUC31DpqtsqR7QgIxn4KiE4mDR
|
||
aSavtG7teg2oiZpNjvWOBYu+i0a4aO8hJBvhrJiNs19oDXmCjQ9tNZG6KYrT
|
||
D4lNkHX6HoJdWxSS0hruUQEa0M3WWBf1vTW0TRUqwB/0bTAN6EfPL28fK63X
|
||
wewAT/KBqhWnjhpG27RFx7uwbpG2sOi877UXJ1x2sGygdeq47s5c7cePOkK4
|
||
h4hGBaeLW7EzCRTExnS85t6krX5AazXKpTHO+aRXwGcXWjy19EwxGwreNmjt
|
||
WbEZ99m0X6IlvIWws853frPnxd3BXj94tLcnL75/c3tyxv/XL1/R55vn//n9
|
||
9c3zK/z85o8X331XPih54s0fX33/3dX4aWx5+erFi+cvr7jxy1e3evKVOnlx
|
||
8ecT1pGTV69vr1+9vPjuhE39xNgEQIO2Qi+XIPQBUCtNVC3EJtgVu4dnl6//
|
||
z/9++mv9/v3fCdT8+FH+QLD58SPJiEfzrtvLn2iOlel7MAF7MV2HWmqT6eIZ
|
||
7kzc+gdHp3Kp1On/RMn8r3P9+1XTP/31H+QLXPDkyyyzyZcks8NvDhqzEI98
|
||
dWSYIs3J9zNJT+d78efJ31nu1Ze//5fOOtCLp7/7lz8o1pG17zr/gBYjQUCY
|
||
EEAPEW3DNvhhs/VDmm7auVJjrHTjB9eeq3N9oVf4EX0XBOvbbCIftpaME5k7
|
||
eIsGaAPiwYygBbJxSqMmhJktQ6dWkEg5BUul/pPcGo6Mi9hZZ3fDTrtht4KA
|
||
BvyYsdTolW0QrGTGg6e0Djh7ca7tgP5e35vOttk2LZV6LZPm5RZA0uodxGg2
|
||
oClAS6jBq702Ts5o2hp0+6zPURul8Zy3tkWzyRYfj3leG82NAj+an22huJU/
|
||
+QQ8eIDY4+RxwqZIU1vXEl7DFfd98PemQxjwF2gyblGaoDM6VfqiZ2uPOKVp
|
||
/K43zsr0dfYEuPTvwLQQGNzTDPLiWoh24wyfWrJ1xdcyHK3FzEI+Q2nz/C26
|
||
QnwIHShO0m3E4aFatNB0hpQo+4elUhXUKF5pl2dVbwq3Zltbb4df8zRrf2Xx
|
||
6zUEUUJPnld0Bi3HgYOvZvEKG/LoWQ94P+hIbekw4aCVGlegAo8Mbkp2MXwG
|
||
5eyYiZOMEOPB6BdNA30yrhHFWKEKuA1HCRTreccaWARAh4twJM6OB8T5kV6W
|
||
jkkeS6Vq9uMNz2B63MlwixqvID0AOJ0ePKr0zoeCdHCXcbx+CAh1lKYxcSq0
|
||
wW4iFJIizYz82mhuSlyp1Bf19y98Cx2Fz/cWHtiwHcYmYuuiRhARABb91kR8
|
||
cLezSe+wj/MMrs8UKiL7FH5gqafmsrVmE8xO264bMBhNglGzFiAJofgEpH2P
|
||
aGh+EpZK/fzzz9rExtqFCUlpCZ8vdPknJ2/8x088m/19SXH2Bz3/d/DN4Rfc
|
||
EmOqDEMXi8XiD7+45eGYi4VGU6Vv4Cd9vKtf2HL27w+fafnfn+3v86Ayyn+/
|
||
5ezf/5fZYr+3ZLD/QV9Bgzh1IqDcEud2yYr9qWX9FWNOuvrr9nMyifl2/k0S
|
||
+vnnn9X7c/3F2m4qGhWPHTNV/3wywyn6hRzNbzv/cPJRqadLfXoqWn96Wrk1
|
||
9uSx9q1iLzs+j/TYUn2FHaAKYOvb8ee2EJNsE+peEIcWdOIS+hyxMuQDo3hA
|
||
pAWFGsEYE2HYg3Wtf1iqr3FUluuTi5UPaTY63JtuIHskznSDwVOivpgOGMc8
|
||
iA11GDpgXslpG+OAHWQbidYMB8T25PiPrmg5t84l7hSyYUItFc5u7YdwNFpd
|
||
6utd35GbZ9ZLETSPQ9/7kHS0+Kvemb9QKISLJu/pWi3oOj9pEoooIqwEZLSs
|
||
xLplKJr5F/oN9/gi9/gn6lGpiwpqRURM0CPysWt2dWlrnN6abp1BBos/QAP2
|
||
HhFSAJVxWVzqiwLEEFxrjPwaPyBi9A8mtLz1PpkOKS8tgBdhhoBd5N/Ado9e
|
||
PvnqsQyF5BOHjzwkkh3IOrxUGmdMXGGByNDZDSEwbBso0L+1NN84dEi7jdAx
|
||
LygvX+T0AyBzAu2410o9Nxnvk4wiqgmuXT/QwzrAOkM9PGEp4JRj4wOSC35n
|
||
rFPwts90A2LDERh0cA/dUn96G3COcdgpxBYiaBmXgg+AlpWZKVQOciBufdfq
|
||
Ry2szdClc/3Nl3+PHZDopfVj2oIfpCfSvhVUp7wlbSM40+qhJyi0ZpWAI2HG
|
||
CjbWkcC5SxETEXJZZ3kXfWhHivT55S1RW1qbobVJpCJ7wUBh8czE6X5c1Bi9
|
||
tl56Z+7EPK0tnoISgZh1gqAjMpyWFN+6fkgzEgrPuX49/iUaSMQHxgKmvbfR
|
||
h72mxiownUVHJIPUkQtF6VYGjASM24furYpEmAsRggZ7qGZDUQWaKXAtWwmU
|
||
r8CnLAJCsSzf4BNxwYF2EhJxJxL7KE28IIQFaZyQvXRA0HyNthLVD/WsD0SC
|
||
Eci1O1hkKr1KHtBBRHJq6Gog+OCHjkC0hJ2DY30mlrCFzuT9fdUnu8N0XjPd
|
||
3foo5IAR9TGfisF1EDGg0n6VT7ONOhgboVWf9jLzpZLVse8wT+B3u8HlxADu
|
||
xhYMx9TBDwkJhunOXri9pqQGVHNYdb65izOrwlogD+W4/ZPqgM9XYhmFKltM
|
||
XNBK6AycXucfFsHGOw5B7yFwBFrPdua4BC9Q2oz3IbMA5cc3Oeac7EaOAmju
|
||
yKUaEfMYQKwtdG0kAvj0NDf80baERPSm8yvCeYOzPw0wMuFhjKWkjdL60fff
|
||
X18xJ47GauwRQgYH3AGFdlXrImVuVGT4I1kqmc314dgHoQy2LtqSxzyGL5Kn
|
||
kPiRdxQXn2S/fYK7cvIgLgVpRbYG+MmXXT6R1cWBlIRlxSRuANPSsYnDbmfC
|
||
/tBpYUMOVbndhC5AgqY/dHZ0ljjsx+ZySvICWzAtUWooF0rDZCrDO/3I0Lkz
|
||
q+i7IeHhx9YxmV2PLJl+/16y4R8/6jfS5pvlb5a/lTUyVstDHXJcGV4wqSW7
|
||
XtlnbPmdjYlDbfLIZSPj6P6Tp57EzlBAc1S3aXl/o16PikjaNNshvYJMASGT
|
||
yysidPIpJc5Yb9TgfJixxStRMcYCgJrEkOaEkMUJUmHGuhNuWezKUaWCt31n
|
||
xIXkQ4BTw8OXSWH6YRwiE7D0NZFK8fGoRaQHeV2URspd6geDuYAoK2LXNQSZ
|
||
17//8IY1B0sqMNWQfybHOHZCCRzyizi887iWfmht5rC+IFNHsB7BCwUS+g2B
|
||
enQshAFmGn1Wh0ASG4BltuwgROD4QNSAByJbwhzlPDDCJWeftdQXhzESKRxQ
|
||
3oclJWirPpwlGPrMILw7OEgFXhjTKY08/GSQAxugnvm0ldhHkKB1TTe0MBnq
|
||
R9ueVdAqoSVnMsko3MBx00qOlMXKLojBPj1/K275BsMy3jX59dJ0zcDZJGa8
|
||
2F4cZ13R509RzhSaVpjGoX2WfXszja1QtmPMIbHFQWSBibvD2OL0NIcLpMeZ
|
||
ke8DRDzTeIpzePbNl3+vZwhcaQ5uRl4fuFPBvSvEvdjxS5/lkA3jP5WonPgS
|
||
VCY71jxxivL0dAQSNL2uG9cgFCZmRiqEVevnPymMhztOVWIMR6m/HILIYcs7
|
||
+QZTh8k2zHJ/a7puhVnnZ7A199YHCaHm+8chLwXOyM6LH1rq63Ver40YQ6qc
|
||
OqwiEHn4nBiPOc6mc8x+iqNpVG2iNm4PUYJ+cfFnHWDBBMnsdGEhk9Gddxuu
|
||
H8uIEoEhILptZapEYVyzBS9RB2pRjZ0nxgaHleQpcNZaG7bQkrRG9yvJ4c8m
|
||
cLX+RP3BQQ53qdSMdsi4EuELvO29Q71Fr2WaO79eMwIW2UTO1opMduYt+e4A
|
||
Kewlyvdr/XXmG/rOpsWzgL70NQJTx4f62k1izBb6zu85SuSzJxUrrIs8x53Z
|
||
a980Q6ATfHHMDkhiC9GxxMwi5cZI/n2PyQDvHJr9e3S3lGcqDEudX5MihGvM
|
||
cJRpZGuDhvaM+CHrFn3wGywtmU+pWPcVQrdI5xLjlmS76SQscRPJC9gRE5LT
|
||
tOI+sh/KJprsaymG4IVGcYpEF5jdETQrccC6sw1VRSKAoy3hEMCSHCTYrn+e
|
||
lh9hRg3ItFUJT66vGccuFUY+qHwYqqoQahNAB+Pucmqulwkwb6JbCMQvZVei
|
||
tB7CBlxTYFLul89UqRpgQmWGdwPicLRMNENh6g7ihonn/SMHy2Va/WTmmY5s
|
||
9doGBjXf+Yfjz1OqqsmC59PjCjAY4/KDpjQSFtZhzosqT0ZPz7v2fKy9SD4X
|
||
XIrtUOp6/dk6DKZEKL0jR3mE4XioLcQz5QOep8pbUHTgmztoz48xHJVBO7Rm
|
||
Q0kgZnum9DGL9svNGU+gKkGZYPljKIaPbk7Pj6Ri1g4sVhQ4PHabB5qu51dx
|
||
YukzBWSyZ6voLvLPmfCSzbsSSeorsirEUrlWPwtg7oSazcLWUjOHXBGLvcpG
|
||
jpq2G9JAarLiRuhzOfH7qLEBgRXnZRkmNHtC7ofmVFSF6xbEEbcDbWmP/EIU
|
||
DG4qsrfAcU6C30Mp5lJlnStZmebU4sZCPJeEheCIEfIQZ9K1gPCoJBqI3Otx
|
||
z6iCSnIVN8a1fqcjCKLnkGKsuUIzgw+sB9dI1pmSEuTOt4DkkKvtmSQjxrM1
|
||
CYxxITYWPW+PKbrUYdXngj1H6WLMhTx4lj/Wft2DXhvbQavm7gSzyQF4wLLf
|
||
nEg+WqfIxv4TdQUT7uf52wSst5x1vSo1tGSpqj6uhE7wAWOpylGZ3DmK04Zp
|
||
HQKfeVPxEqotHQm7s6yHMfVUkeLG+Ul0hHo3FvmO+L7Ki6wwH7/qbEQTl4sO
|
||
qGGAjSXN46DnYlI5PE6pthwSMVD7g2h/dB95ynPiqZJDTsWFYKhZXZZArE88
|
||
07lcG+N36zZ89eH0FG9GFPJpbIZfj5FW9YOsc09pyEcRQL9/P/68yD9//Ph4
|
||
KSMQazjqufx5UFay13YCHnPz3mBxIsZE2MO4lYuxOqQu8Nbj87kHVPeEUDET
|
||
PDub8emxMopHsNwsz5A0BVpkh8/Hs+LHerPvvGl1tO+gLNLcG9tJPzRPLlXW
|
||
9fdYsZyGqB+dyLcdEIWn9clqiHskW1rYBNMymTe48bHHmX4YJ3vJl2YsxriX
|
||
9ZlAPyoXVrjaxM/opqa0HLmGfuCU7OvgGyxaQYuFkOOMqzywpBwrXhvMOZmE
|
||
fH8KxkW5HpHphP9w/qGDdkNdXVFuSle5KUQlkQpp7vKDGm1yPOP+SDGpf02H
|
||
0GwkZL31vqPKnRiZrEgop/EyCB7jwLlVj7WKF6+voxRvYXrFNiAB9QUDuXeS
|
||
2Gg8K/9rjPLjeGdBJkpgL1bWQWvMfHHVrQkW7yPITYTMBYpy040orA5LVrbr
|
||
BSRDkpNg9RMmaQot8lkp91C8U8nnkuhmMkCzheaODjYzy9b9ODt5mQ8tmCh3
|
||
L9nezIjuzNuDpln3/4umLbITqF9t7oFtk+6EVc3fSolVgLEHpfVqQCeWu1hO
|
||
HcFYOm1GLFJalxlxFK+ss+StSN+nJ5yDlSsuuT56W403s/7lWrqTvZXCLv2i
|
||
XHxAk3+k+Ay9uUwFWs7GlboyoVuwwrG2vCgYm3TrgegJ3Xu8XBBJOFszvwli
|
||
HGEwRV3+Kk61aVn4i0ocUrABjlK7p6f1Mm/wFkZMp6eZOEGoKEgGU4JI48y9
|
||
BMqjNrrCg/AVprJURG5tzJTHfFQuzjw9xbGqmswH23XWbZxYjaIBBKIukOll
|
||
KZP3ZOCEeUB2zxSv4p2pHBZU27NUSrYw6q1BPDl6EWL4hYgZc9y/+VJHaHAN
|
||
dJNDZQyOLDdGe91eNx1Feat9pngxui/ZSCwPfHKJRAaEBf2ln0t1r1KvHBXQ
|
||
VkpTreT8l+zivMDys1tYahgpr9SK62SfV/wd2WG6ASM9iL4Scnp8fJ+RS5G9
|
||
pq2ma3BkeCkgZR4zlyqLY6LCyTypZW4wkRS2e+FbVnqefGYjRCT4F5FcujCO
|
||
pasbyImvG1gPUlSUs6NTDHImCso9VXnTr5c6z4gLX2mpCKesG0AY5Gwl/Vp/
|
||
k6G1mCPZgNpCZA1qPFv7ljMBGE64EoOP5aocvnEUKLTJCpl1opCoZkmuTZF8
|
||
hMua6EWRPJ8VvDmHRmnEhDX/jp2cKS5aYqWejMbAe5ZZyYHsWI0ujgxVVLKy
|
||
iHflVzq1Z1VqYlpQO9qUMz2qKLlnl7FaBe1wcEo1mMpnbL0TPalu+xBPZgn9
|
||
91ZgBGGFfJYx1S1X12QbbmBRG6wrRv43fJtJqefVeSfmNZt8ZDcn93bWzM4k
|
||
jmHzpcMSed+Uy3M1bmQrQSt8CQ/1osmD2l1fDE8GQmvTYChVCgSC3Yz7Sq2c
|
||
F+JZmxZ+GsiqqpvpdHP5b6HeSPefNPVJGDHBCqtWQHAiNyJmgc3VuOnLefx4
|
||
I0GDfv/FsVAil0513QIBpqub3u57iPN7GTMPlaklJoBMdsidBkc8FLLcn4hy
|
||
zpX6QGPo6yv9IWPuvf5Q4lUU0weFVablP/WBoNmQYFlgMzbm7/QHKb4ef4Ny
|
||
OatuWwD2pO0VWuUp9mYPPAJ37KQA7CWXiOkPuoBz7IW+HEOoAtJnjZmpw6Kw
|
||
afvrEZDq8RmKF2fQnjpEWL40vdUfdAXl9QfiB0hfL15fU2F8hvWlVSWbWVv6
|
||
ywfN+zATIjK275YtXxrHGU+R/4d8nxwVYvJLxJig6oLZ/SMdXAZoJZ1B8i8h
|
||
hJBDTV4IVtwms1pUqs1aKTW3n1Hsk48VjcKAs7AS6HIuh5j8Ttfhn1KvqpcV
|
||
RLJGrPq64acPTkcmUbjAB5RoDL4SAfmwtX2bY+KTxu+W8NZgoL7k7qplnTxe
|
||
yozUfAwybiXvMKWrH3D9d7T+ObSsqi/QktWFfng+CTZQH9cXLy9IInS5gpgy
|
||
6YcgN37rmCjFh1YB4/chUnQ5CbjMvIihrnIh16N3ptlaB+UR9JHNFnaGuq6B
|
||
sPqCChCraLW+CPbpW9+a8lnxgOYVkld95i5ndZPzM3cwq0udNRQyNa1JBZMU
|
||
lHfzIq/n+Y6pdbTAl749tMF4HH80TcLc2TAzwXyBqbw4IN+hzXTEWFLVj5Xm
|
||
fCVWXFHJF/I9oZFb1eTtcFLOt5/h6anaIKdvCuOW8ziFE5a6qHml173Ur+c5
|
||
GSn7wEx8dXNqmSej9C+ZDiX+x7mMKSiZ1VjU+ciu86a1j+eTa0rhSC0yuRDG
|
||
8jpI3v1VYqsLNPBWkvT8aFbO8njMejBV/as4FnEcQIBpOMjzZvWa3N46ckoo
|
||
1ZdPyJgDwsXA26QeQbadj3XTGburKutKjun0FN4iKqYH5hbhZDylP1bjnwi1
|
||
yonfGkGPQenZ3KJNL4GjRdDjfclFFRsROM9GZ4SjE9NAjG65fYldlR0koziB
|
||
vT/aVvrq4B6rjyXcQsy5+JTxKWiOdSiDyLpTUc4sLgoSWGXgnggy/HXoW85m
|
||
lBtqb6AZKB15WV/Z5Ftqb/Yr2yEUtpEiH6VuPfVHhKrTJiV6EwrjDZZUfX9/
|
||
be5gUr5HfjF5RFzdICUnxfrITUkOmOq8w4AXOhJVRYleVeaxKd4/8sU+Dj85
|
||
RVG/FSCf5+WRdKZgi/lUcyEKJ3HLFU/s4fLIZY/sFq1rfOj5hR0lh1BjEfJU
|
||
PoCQbz0409l3GJQ+dPvapWIy1XHLfHGeNaXQA3IFMZM7Y+oj7xPWS/e2HfWY
|
||
ipwi7ey4UjYDz/bvsLzHgf4WuRZ96zsIFPLOleMTFbKxzu5O78vLNRGxlopq
|
||
ycfxiNvRqYz36Nm3t4+X+qoqG2HSA9f77NtbtRlMMC7hdVCWOqnN9xF0LsOt
|
||
K9XpEI7XNUTucp+jUMoBOpttxNZitQYpSyml0U3wMS6oBqVEkVzJKjfO6+os
|
||
paf4E0XkoGP8BClnXMs1DiLWSh3ZV+v/8VQqZda5Sk1YDXRi42Vxn1j7uz0L
|
||
cV+pSd61CRv37Nvb6g0fgidfo7yp8AuVs3oZy9E6aIQNWM2wiNl4gLu3wbv8
|
||
XpapS3nTe7/mVPe87qWkFCfJRHobTVYYJl2X6oVNdiNYus7bfTqnWCpzmDkZ
|
||
XZJQtGWHoK3NSJbcsEN2Sc60bPokNhUvlvc+QUxUAJB9RLEfAbq9HNS0BZZf
|
||
uWcxoq6qMoj0E5PEqBQtdPae6AFZXjsVFxMs5h6K3ZvouhSwsYfphWoaVxFl
|
||
d8rtknKHCt423cAX+4Pf0QUQqvs8yFrPX4oifrdcSoDQjLmYTvos5RDkVSRx
|
||
Xq7g47sJjLO9VIlO39g0cRVU9d2bhCpbX0GiN/K8E5CLCT+qkKQg0e9MZ6kw
|
||
RNSfDSH+WLBdPNNx75pt8Jy+wxJLt3lc7VEdBMnLGZKX+5diFibFmmSG/IA6
|
||
Mobmfj25s/8racjUGBVA0tGmGzJoh7hqO4LpoF2sbCtl5I+zV0PgUUUMkqGK
|
||
eIzSYuub8V1GbLv4KhILj18hIKHefjQtVEY9xFwxNamBqMXgvGRDJLuCYkbg
|
||
cTgMxyCp1Dhx2HgEgYxutoQxf6IwZv7up8D5kjj1gZLaPgyGlARD1fW0MsCE
|
||
cqLR5iwT0teZTTrCOM2CJqQsZldzJxf8OcL5oKcLmnZFYU3uB8ObEuvQa0Z+
|
||
YS8SGHzId8v471gihXik+Pqwx0yjoMAWKLCDK8uzvWLyZM6pFLLxk1tJSpG8
|
||
8OP0TomH8n7C0pligqZs2wi5x22f84wmTqPyY6wQldEiyzuSkwxpykBy7PWb
|
||
yZ3gGzEG6lG5KIPvKvz48fFYMlb7r4tMyM+Ilnyia4cjrCfXc32aIOHfq5jB
|
||
S9JpzbHR5BKzvJUOK4HxJF402TiRE1XvzxlsQPvPJ2vTRcDdvC2lmHQt8i6/
|
||
P8VxwS+aBRkT3/+JL3Ki3B+9G4YqewZJ+Xk3vizP49s7y9FFWX3qRWiq2Zqu
|
||
A6bi/y8mbyizFlUAAA==
|
||
|
||
-->
|
||
|
||
</rfc>
|
||
|