Network Working Group I. Schrock Internet-Draft EMILIA Protocol, Inc. Intended status: Experimental 21 July 2026 Expires: 22 January 2027 Model-to-Matter: Authorization Evidence for Model-Directed Physical Execution draft-schrock-model-to-matter-01 Abstract Advanced models and agents can propose experimental workflows and invoke systems that produce physical effects. Before acting, a physical executor may need evidence from several independent authorities: model provenance, a safety assessment, institutional authority, a domain review, an external screening service, and an accountable human. Those artifacts are commonly evaluated separately and may not bind the same action. This document defines Model-to- Matter, an experimental executor-side applicability profile for composing those artifacts over one canonical, digest-only action. It specifies an executor-owned acceptance profile, normalized signed evidence adapters, a registered challenge, closed clearance and refusal verdicts, atomic single-use clearance consumption, and an optional executor-signed effect statement. The profile composes native evidence through an Authorization Evidence Chain and applies the Action Evidence Boundary lifecycle when the executor invokes the effect. It does not perform domain screening, determine scientific safety, authorize an institution, or establish physical truth. It standardizes the point at which an executor refuses to act unless the authorities it independently trusts agree about the same action. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 January 2027. Schrock Expires 22 January 2027 [Page 1] Internet-Draft Model-to-Matter July 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Model-to-Matter Action Object . . . . . . . . . . . . . . . . 5 5. Relying-Party Profile . . . . . . . . . . . . . . . . . . . . 6 6. Normalized Evidence Artifacts . . . . . . . . . . . . . . . . 7 7. Registered Challenge . . . . . . . . . . . . . . . . . . . . 8 8. Clearance Evaluation . . . . . . . . . . . . . . . . . . . . 8 9. HTTP Integration . . . . . . . . . . . . . . . . . . . . . . 10 10. Executor Effect Statement . . . . . . . . . . . . . . . . . . 10 11. Relationship to Staged Authorization Programs . . . . . . . . 10 12. Optional Durable-Consequence Profile . . . . . . . . . . . . 11 13. Relationship to Bounded Capabilities . . . . . . . . . . . . 11 14. Security Considerations . . . . . . . . . . . . . . . . . . . 11 15. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 17. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 18. Changes since -00 . . . . . . . . . . . . . . . . . . . . . . 13 19. Normative References . . . . . . . . . . . . . . . . . . . . 13 20. Informative References . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction A digital proposal can become a physical effect when a model or agent can call a cloud laboratory, instrument gateway, robot, manufacturing system, or other executor. Existing controls answer important but separate questions: which model and harness produced the proposal, whether an assessment ran, whether the principal had institutional authority, whether a domain reviewer approved the workflow, whether an external screening service returned an acceptable result, and Schrock Expires 22 January 2027 [Page 2] Internet-Draft Model-to-Matter July 2026 whether a responsible human approved execution. None of those facts alone answers the executor's question: do all authorities required by this executor agree about this exact model, harness, protocol commitment, material commitment, purpose, facility, destination, and one permitted clearance? A presenter can otherwise splice valid artifacts for different actions or choose a weaker sufficiency rule. Model-to-Matter defines the relying-party side of that boundary. The executor constructs the Action Object, pins its own profile and issuer keys, challenges for the required evidence, and refuses every result except a closed clear_to_execute verdict. The challenge and the action are consumed in durable shared state before the corresponding execution can be credited. 1.1. Scope and Non-Goals This document specifies evidence composition and execution custody. It does not define a domain's safety criteria, inspect sensitive scientific content, replace an institutional review process, certify a model or facility, or decide whether an experiment should be approved. Each substantive judgment remains with the authority that signs the corresponding evidence artifact. This document also does not prove that a physical effect occurred or that sensors reported it accurately. An effect statement proves only what a pinned executor signed. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. Executor The system that controls the physical or external effect and evaluates Model-to-Matter evidence before acting. Action Object The executor-computed, canonical representation of one requested physical action. Evidence issuer An independent authority that signs one normalized evidence artifact. Signature validity does not itself make the issuer accepted. Relying-party profile The executor-owned acceptance policy, Schrock Expires 22 January 2027 [Page 3] Internet-Draft Model-to-Matter July 2026 including evidence types, issuer keys, freshness, revocation, action types, and human-assurance floor. Clearance A closed executor verdict. Only clear_to_execute permits the guarded execution path. 3. Architecture The Model-to-Matter lifecycle has the following participants: 1. The executor constructs an Action Object from the operation it is actually prepared to perform. 2. The executor selects a relying-party profile and registers a short-lived challenge binding the action digest and profile digest. 3. Independent issuers produce typed evidence artifacts bound to that action digest. 4. The presenter submits an evidence graph in response to the challenge. 5. The executor atomically consumes the challenge, verifies every evidence leg under its pinned profile, and emits one closed verdict. 6. Before returning clear_to_execute, the executor atomically consumes the action digest so separately issued challenges cannot authorize the same action twice. 7. After attempting the effect, the executor may issue a signed effect statement. The presenter's graph and requirement are descriptive. They MUST NOT select issuer keys, accepted evidence types, revocation policy, or the assurance floor used for clearance. The evidence set is evaluated under the Authorization Evidence Chain discipline [I-D.schrock-ep-authorization-evidence-chain]. Each evidence leg is verified under its native rules before CAID comparison; the executor then evaluates its own evidence requirement. A satisfied requirement is not yet local authorization and is not proof of execution. This profile adds the physical executor lifecycle and fixed initial evidence roles. Schrock Expires 22 January 2027 [Page 4] Internet-Draft Model-to-Matter July 2026 4. Model-to-Matter Action Object The initial Action Object version identifier is EP-MODEL-TO-MATTER- ACTION-v1. It is an I-JSON [RFC7493] object serialized with JCS [RFC8785]. Its action digest is "sha256:" || lowercase-hex(SHA- 256(JCS(action))). The initial action_type is science.bio.experiment.execute.1, registered by the CAID package. The executor MUST also compute the jcs-sha256 Canonical Action Identifier (CAID) [I-D.schrock-canonical-action-identifier] over the same closed Action Object. The CAID's base64url digest component and the hexadecimal action_digest MUST decode to the same SHA-256 octets. A mismatch is a refusal. CAID supplies portable content identity only; it does not establish identity, authority, authorization, execution, safety, or legal reliance. The initial profile requires these members: +====================+============================================+ | Member | Required binding | +====================+============================================+ | @version | The version identifier above. | +--------------------+--------------------------------------------+ | action_type | science.bio.experiment.execute.1. | +--------------------+--------------------------------------------+ | model | Provider and model identifiers plus | | | manifest, harness, and safeguards digests. | +--------------------+--------------------------------------------+ | experiment | Protocol digest, material commitment, and | | | expected-effects digest. | +--------------------+--------------------------------------------+ | principal | Organization and principal identifiers. | +--------------------+--------------------------------------------+ | executor | Executor and facility identifiers. | +--------------------+--------------------------------------------+ | purpose | Purpose code and jurisdiction. | +--------------------+--------------------------------------------+ | destination_digest | A digest of the intended destination | | | representation. | +--------------------+--------------------------------------------+ | requested_at | An RFC 3339 [RFC3339] instant. | +--------------------+--------------------------------------------+ | max_executions | The integer 1. | +--------------------+--------------------------------------------+ Table 1 Schrock Expires 22 January 2027 [Page 5] Internet-Draft Model-to-Matter July 2026 Unknown members MUST be rejected by this version. Portable objects MUST NOT contain raw sequences, raw protocols, prompts, completions, hidden reasoning, or equivalent sensitive source content. Such content remains in the source systems; only agreed digests or hiding commitments cross this boundary. A plain digest of low-entropy material is not a hiding commitment and MUST NOT be represented as one. The executor MUST compute the Action Object from the operation it will perform. It MUST NOT accept a presenter-supplied digest as a substitute for independently constructing and hashing the action. 5. Relying-Party Profile The initial profile version identifier is EP-MODEL-TO-MATTER-PROFILE- v1. A profile binds: * a stable profile_id and equal policy_id; * the reliance purpose frontier_science_execution; * the complete required evidence expression; * allowed action types; * a required human-assurance value; * per-type freshness limits; * the evidence types for which explicit revocation state is required; * accepted pairs of issuer identity and public key for each evidence type; and * a non-disableable same-action-agreement requirement. The initial human-assurance wire values are software, class_a, and quorum, corresponding to software evidence, a device user-verified human, and a quorum of distinct device-verified humans. An implementation MUST reject unregistered values, including class_b. A physical-execution profile SHOULD require at least class_a; policy determines when a quorum is required. The profile MUST be provisioned through a relying-party-controlled channel. A profile or key registry received with presenter evidence MUST NOT be used to authorize that presentation. Schrock Expires 22 January 2027 [Page 6] Internet-Draft Model-to-Matter July 2026 6. Normalized Evidence Artifacts The initial evidence version identifier is EP-MODEL-TO-MATTER- EVIDENCE-v1. An evidence artifact contains evidence_type, action_digest, issuer_id, issued_at, expires_at, a closed claims object, an optional outcome, and a signature envelope. The initial profile requires exactly one accepted artifact of every following type: +=========================+=========================================+ | Evidence type | Minimum same-action claims | +=========================+=========================================+ | model_attestation | Provider, model, manifest, | | | harness, and safeguards. | +-------------------------+-----------------------------------------+ | safety_case_attestation | Model commitments, safety-case | | | digest, and assessment. | +-------------------------+-----------------------------------------+ | institutional_authority | Organization, principal, action | | | family, purpose, and decision. | +-------------------------+-----------------------------------------+ | biosafety_review | Protocol, material commitment, | | | facility, and decision. | +-------------------------+-----------------------------------------+ | domain_screening | Material commitment, | | | destination, screening-profile | | | digest, and decision. | +-------------------------+-----------------------------------------+ | human_authorization | Approver, decision, and | | | assurance evidence. | +-------------------------+-----------------------------------------+ Table 2 These names identify evidence roles, not authorities owned by this specification. For example, a domain_screening artifact reports what an accepted screening issuer signed; the Model-to-Matter verifier performs no screening itself. The initial signature algorithm is Ed25519 [RFC8032]. The signed bytes are the UTF-8 encoding of the version identifier, followed by one zero byte, followed by JCS of the artifact without its signature member. Each artifact MUST bind the exact action digest. The relying party MUST first verify the signature and then separately decide whether the exact (issuer_id, public_key) pair is accepted for that evidence type. Schrock Expires 22 January 2027 [Page 7] Internet-Draft Model-to-Matter July 2026 7. Registered Challenge The executor creates and durably registers a challenge binding the server-computed action digest, the profile digest, a nonce, the required evidence types, an expiry, and an authorization endpoint or equivalent acquisition mechanism when one is available. The challenge follows the Action Evidence Boundary acquisition and enforcement rules [I-D.schrock-action-evidence-boundary]. A discovery declaration can describe that mechanism, but live executor configuration remains authoritative. Challenge state MUST provide atomic first-presentation consumption across all executor replicas. Storage unavailability, rollback, or an ambiguous consumption result MUST yield refusal. An implementation MUST NOT fall back to process-local state. At the clearance API boundary, storage exceptions and ambiguous consume results MUST be mapped to do_not_execute_refused; they MUST NOT escape as an untyped result that a caller could mistake for authorization. A missing-evidence refusal MAY include a new registered challenge that names only the missing types. A follow-up challenge is a new transaction; it does not reopen the consumed challenge. 8. Clearance Evaluation An executor evaluating a presentation MUST perform these steps in order: 1. Clone or otherwise snapshot the action, profile, challenge, and evidence graph before the first asynchronous operation. 2. Validate the closed object shapes and resource bounds. 3. Recompute the action digest, CAID, and profile digest, and require the CAID and action digest to encode the same SHA-256 result. 4. Require the challenge bindings and current time to match. 5. Require an explicit revocation view for every profile-required evidence type. Absence of revocation state is not proof of non- revocation. 6. Atomically consume the challenge. Schrock Expires 22 January 2027 [Page 8] Internet-Draft Model-to-Matter July 2026 7. Verify each artifact under its native rules, including its signature, issuer identity and role-scoped key pin, time window, revocation state, same-action binding, and type-specific claims. 8. Evaluate the relying-party-pinned AEC requirement, require exactly the evidence roles named by the profile, and reject duplicate, conflicting, unknown, or action-mismatched components. 9. Apply the executor's separate local authorization decision. AEC satisfaction alone MUST NOT permit the physical effect. 10. If and only if all checks pass, atomically consume "model-to- matter:" || action_caid in a durable shared store. 11. Return clear_to_execute only when the action consumption is the first successful consumption. Every other outcome is a refusal. The initial clearance version identifier is EP-MODEL-TO-MATTER- CLEARANCE-v1. Its closed verdict set includes clear_to_execute, do_not_execute_missing_evidence, do_not_execute_stale_evidence, do_not_execute_conflicted, do_not_execute_unverifiable, do_not_execute_action_mismatch, do_not_execute_refused, and do_not_execute_malformed. Unknown verdicts MUST be treated as refusal. An action-bound clearance carries both action_digest and action_caid. The executor computes both fields; a presenter MUST NOT supply either value as a substitute for the Action Object. Consumption of the action digest MUST be non-expiring for as long as the action can be presented. An unavailable response after consumption is an indeterminate outcome that requires reconciliation. The executor MUST return do_not_execute_refused, mark reconciliation as required, and freeze execution; availability MUST NOT silently become a second clearance. After an indeterminate storage outcome, the enforcing executor MUST remain fail-stop and MUST NOT issue another challenge or evaluate another presentation until an operator has reconciled the durable challenge and action-consumption state. Schrock Expires 22 January 2027 [Page 9] Internet-Draft Model-to-Matter July 2026 Before invoking an external provider, the executor MUST durably record a dispatch-pending state bound to the action CAID, operation identifier, selected provider, and consumed clearance. After that record exists, a timeout, connection loss, process crash, or unclassified provider error MUST become indeterminate, not a retryable failure. The executor MUST NOT blindly invoke the action again. It MAY reconcile the original operation only from authenticated, exact-operation provider evidence or an authoritative system-of-record result. 9. HTTP Integration An HTTP executor MAY use status code 428 (Precondition Required) [RFC6585] to return the registered evidence challenge when clearance is absent. A client that cannot satisfy the challenge remains unable to invoke the physical effect. HTTP transport does not replace the atomic challenge and action stores. 10. Executor Effect Statement After an execution attempt, the executor MAY sign an EP-MODEL-TO- MATTER-EFFECT-v1 statement containing the action digest, action CAID, clearance replay digest, executor identity, execution time, status, and observed-effect digest. The statement MUST bind a prior clear_to_execute clearance for the same action and MUST verify under a relying-party-pinned executor key. Valid statuses are completed, failed, aborted, and indeterminate. A reconciliation statement MUST bind the original operation identifier, effect-statement digest, action CAID, authenticated provider-evidence digest, and prior status. It appends a new conclusion and MUST NOT rewrite or erase the original uncertainty. The statement establishes only that the pinned executor signed those claims. It does not establish sensor integrity, causal attribution, or physical truth. 11. Relationship to Staged Authorization Programs A deployment MAY require an ordered authorization program in which one stage becomes eligible only after the predecessor stage receipts are complete. Each stage receipt binds the same root action CAID, the stage identifier, the exact predecessor receipt digests, and its own execution binding. The executor MUST verify the stage program independently; CAID equality alone does not prove stage order, quorum completion, authority attenuation, or eligibility. Schrock Expires 22 January 2027 [Page 10] Internet-Draft Model-to-Matter July 2026 A stage that authorizes a materially different physical action uses a different CAID. The program can bind that child CAID to the root program in its own signed state. This preserves the distinction between content identity and the multi-party ceremony that authorizes progression. 12. Optional Durable-Consequence Profile A deployment MAY combine this profile with durable capability reservation, action escrow, terminal certificates, witness cosigning, or external state-root anchoring. Those mechanisms can preserve budgets and evidence across failures, but they do not change the clearance rules in this document. They remain optional deployment mechanisms rather than prerequisites for Model-to-Matter conformance. A durable-consequence mechanism MUST keep resources locked while an invocation is indeterminate and MUST release or compensate them only under the mechanism's authenticated reconciliation rules. An on- chain record or witness signature is evidence under its own verifier; it is not proof of physical truth, scientific safety, or legal effect. 13. Relationship to Bounded Capabilities A deployment can require a Bounded Capability Receipt ([I-D.schrock-ep-bounded-capability-receipts]) as an additional machine-authority input before creating a clearance. That capability can constrain aggregate budget, validity, holder proof, and action scope across operations. It does not relax this profile's single-use rule. Every Model-to- Matter action still requires its own action-bound clearance, and each clearance remains terminal after one execution attempt. A capability reservation is an additional precondition; it is not a reusable clearance, does not satisfy any of this profile's six evidence roles, and is not evidence of scientific safety. Threshold reconstruction of a holder secret MUST NOT satisfy the quorum human-assurance value. 14. Security Considerations *Executor bypass.* Model-to-Matter is effective only when every path to the protected effect traverses the enforcing executor. Alternate instruments, privileged maintenance paths, or direct backend access remain part of the trusted computing base. Schrock Expires 22 January 2027 [Page 11] Internet-Draft Model-to-Matter July 2026 *Presenter-selected policy.* Verifier code, issuer keys, profiles, revocation rules, and requirements MUST be pinned before a transaction. Accepting them beside evidence lets a presenter define the proof that its own evidence must pass. *Cross-action splicing.* Every evidence artifact, challenge, clearance, consumption key, and effect statement MUST bind the executor-computed action digest. Clearances and effect statements MUST also bind the recomputed CAID, and both identifiers MUST name the same canonical bytes. A valid artifact for a different action is unsatisfied. *Issuer laundering.* A signature proves control of a key, not authority for an evidence role. Acceptance MUST bind both issuer identity and key independently for each evidence type. A key accepted for one role MUST NOT satisfy another. *Replay and ambiguous effects.* Challenge consumption prevents replay of one presentation; action-digest consumption prevents separately minted challenges from clearing the same action. Both stores require atomic shared state. After the effect begins, an unavailable response MUST leave the action consumed or frozen. *Revocation completeness.* An empty or absent revocation view is not evidence that nothing is revoked. This profile requires an explicit view, but the authenticity, freshness, and completeness of that view remain deployment responsibilities unless a separately verifiable revocation mechanism is used. *Human authorization.* A human evidence artifact is only as strong as credential enrollment, authenticator custody, user verification, and the presentation shown to the approver. A signature does not prove that the human understood the action. *Substantive judgment.* Cryptography cannot prove that a model is safe, a review is correct, screening is complete, an action is lawful, or a physical result is benign. This profile MUST NOT be deployed as the sole control for a safety-critical physical effect. Independent technical, organizational, and operational controls remain necessary. *Resource exhaustion.* Implementations MUST bound object depth, node count, string bytes, evidence count, identifier length, and parser work before signature or graph evaluation. Schrock Expires 22 January 2027 [Page 12] Internet-Draft Model-to-Matter July 2026 15. Privacy Considerations Action, evidence, and effect objects can reveal model use, institution, facility, principal, approver, purpose, destination, and timing. Profiles SHOULD minimize identifiers and use pairwise or pseudonymous values when accountability requirements permit. Logs require retention and access controls appropriate to their jurisdiction. Digests do not automatically provide confidentiality. Low-entropy or enumerable inputs can be recovered by guessing. Deployments handling sensitive material SHOULD use domain-separated hiding commitments with adequate randomness and keep openings outside portable evidence. 16. IANA Considerations This document has no IANA actions. A future revision may request media types or registries after the object model and deployment experience have stabilized. 17. Implementation Status An Apache-2.0 TypeScript reference implementation with generated Node-compatible runtime companions, a synthetic self-checking demonstration, and adversarial tests are publicly available. The implementation covers the Action Object, profile, six signed evidence adapters, registered challenge, evidence graph, single-use clearance, and effect statement. A deterministic public suite exercises 15 CAID, acceptance, refusal, replay, storage-failure, and effect cases; 41 focused tests and a mutation-score floor exercise the reference implementation. It has no Python or Go port, no wet-lab deployment, no external scientific validation, and no claimed partnership or endorsement. The demonstration does not process raw biological content or perform screening. 18. Changes since -00 This revision replaces the standalone challenge and evidence-graph dependencies with the AEB and AEC composition boundaries, adds durable dispatch-pending and no-blind-replay requirements for uncertain provider effects, defines append-only reconciliation, explains staged authorization programs and optional durable- consequence mechanisms, and updates the implementation language to TypeScript. It does not claim a wet-lab deployment, scientific validation, screening capability, independent implementation, partner, or endorsement. 19. Normative References Schrock Expires 22 January 2027 [Page 13] Internet-Draft Model-to-Matter July 2026 [I-D.schrock-action-evidence-boundary] Schrock, I., "Action Evidence Boundary", Work in Progress, Internet-Draft, draft-schrock-action-evidence-boundary-00, July 2026, . [I-D.schrock-canonical-action-identifier] Schrock, I., "The Canonical Action Identifier (CAID)", Work in Progress, Internet-Draft, draft-schrock-canonical- action-identifier-01, July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 20. Informative References Schrock Expires 22 January 2027 [Page 14] Internet-Draft Model-to-Matter July 2026 [I-D.schrock-ep-authorization-evidence-chain] Schrock, I., "Authorization Evidence Chains: Composing Heterogeneous Agent-Authorization Receipts", Work in Progress, Internet-Draft, draft-schrock-ep-authorization- evidence-chain-04, July 2026, . [I-D.schrock-ep-bounded-capability-receipts] Schrock, I., "Bounded Capability Receipts and Durable Spend Control for Agent Actions", Work in Progress, Internet-Draft, draft-schrock-ep-bounded-capability- receipts-00, July 2026, . [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, . Author's Address Iman Schrock EMILIA Protocol, Inc. United States of America Email: team@emiliaprotocol.ai Schrock Expires 22 January 2027 [Page 15]