IETF Drafts
IETF drafts help express OAN-related ideas in a form that can be reviewed beyond one implementation or community. They are not a replacement for the codebase or the papers, but they are important for interoperability: they force the architecture to be described in protocol-facing language.
The central question is how heterogeneous agent resources can be identified, registered, discovered, and verified before interaction.
That question is intentionally narrower than “standardize every agent protocol.” OAN-related drafts should help define the trust and Discovery layer around resources while leaving room for MCP, A2A-style systems, APIs, skills, and domain protocols to continue evolving.
OAN Resource Identity and Discovery
The OAN resource identity and Discovery draft frames the core OAN idea: trusted resource identity and discovery for open agent ecosystems. It is the closest standards-facing companion to the OAN architecture. It helps explain why resource DID identity, governance, Root-verified publication, and Discovery evidence belong together.
Readers reviewing OAN’s trust model should start with this draft after reading the white paper or yellow paper.
Reviewers should look for whether the draft makes the key separations clear: resource identity versus endpoint, registration versus Root acceptance, Discovery result versus invocation permission, and capability metadata versus authorization scope.
Agentic Overlay Network Architecture
The Agentic Overlay Network architecture draft places agent systems in a broader network architecture discussion. It is useful for understanding how agentic systems may form overlay structures above existing Internet and application protocols.
OAN can be read as one trust-governed infrastructure approach within this broader agentic networking direction.
The overlay framing is helpful because OAN sits above ordinary networks and application protocols. It does not replace IP routing, TLS, HTTP, MCP, or agent task exchange. It provides a higher-level trust and discovery substrate for agent-facing resources.
Efficient Agent Discovery Profile
The Efficient Agent Discovery profile draft focuses on metadata and query profile design. It is relevant to OAN’s Discovery layer, especially when query fields, metadata fields, ranking, and structured filters need to be described in a way that can interoperate.
This draft pairs naturally with the GRAIL semantic Discovery direction: one emphasizes standards-facing metadata and query shape, while the other explores retrieval quality.
For implementers, the useful question is whether a Discovery API can expose enough structured metadata for both simple filters and advanced semantic retrieval. A profile that is too thin cannot support good search; a profile that is too rigid may block future resource types.
How Drafts Relate to Implementation
Drafts should not be read as detached from implementation. A useful standardization path is grounded in running services, SDK behavior, concrete resource packages, Discovery responses, verification logic, and operational lessons. OAN’s public implementation and website Docs can supply that grounding.
At the same time, drafts help prevent the implementation from becoming too local. They push the design to define terms, boundaries, and interoperability assumptions clearly.
They also create a neutral review surface. External readers can critique protocol objects and security assumptions without needing access to private operational repositories or deployment secrets.
What Reviewers Can Look For
Reviewers can ask:
- Are identity, publication, discovery, and invocation responsibilities separated clearly?
- Is the trust model understandable without private operational knowledge?
- Are protocol objects stable enough for independent implementations?
- Are domain scope and capability metadata clearly distinguished?
- Does Discovery return enough evidence for clients?
- Does the draft avoid assuming one runtime protocol for all resources?
These questions are exactly where standards review can improve OAN.
Good standards work should feed back into tests and SDK behavior. If a draft clarifies a field, the SDK should expose it consistently. If review finds ambiguity in freshness, signatures, or domain scope, the implementation should add conformance cases rather than leave the ambiguity in prose.