Context
TMF catalog standards (serviceCatalogManagement, resourceCatalogManagement) describe what exists but not what it can do — they are poor inputs for automated ordering or reasoning. They also present a multi-domain problem: if you have multiple network domains not all running diffo, or you want a consolidated view across domains, a synchronised catalog store becomes a coordination burden with no clear owner.
The obvious diffo approach — introspecting the provider do DSL to generate catalog entries — would work technically (all the metadata is already there: id, name, type, major_version, tmf_version), but produces the same impoverished artifact the standards describe.
Alternative
An agent-to-agent protocol. The consumer agent talks directly to the provider agent: "can you give me a shelf with 4000 VLAN tags in Auckland?". The provider agent can answer meaningfully — constraints, availability, negotiation — because it has live access to the graph and the DSL. No static catalog document required.
Benefits:
- Richer than any catalog standard allows
- Multi-domain federation falls out naturally from agent topology — no synchronised store needed
- The catalog is always current because it is the system, not a snapshot of it
Open questions
- What does the provider agent API look like? (MCP server over the diffo domain?)
- How does a consumer agent discover provider agents in a multi-domain topology?
- Is there any value in a lightweight machine-readable index (not a full catalog) for bootstrapping discovery?
Decision
Diffo may never implement a TMF catalog. This issue tracks the exploration.
Context
TMF catalog standards (serviceCatalogManagement, resourceCatalogManagement) describe what exists but not what it can do — they are poor inputs for automated ordering or reasoning. They also present a multi-domain problem: if you have multiple network domains not all running diffo, or you want a consolidated view across domains, a synchronised catalog store becomes a coordination burden with no clear owner.
The obvious diffo approach — introspecting the
provider doDSL to generate catalog entries — would work technically (all the metadata is already there:id,name,type,major_version,tmf_version), but produces the same impoverished artifact the standards describe.Alternative
An agent-to-agent protocol. The consumer agent talks directly to the provider agent: "can you give me a shelf with 4000 VLAN tags in Auckland?". The provider agent can answer meaningfully — constraints, availability, negotiation — because it has live access to the graph and the DSL. No static catalog document required.
Benefits:
Open questions
Decision
Diffo may never implement a TMF catalog. This issue tracks the exploration.