Internet-Draft Graph based Meta Schema for collaborativ November 2025
Henderickx Expires 6 May 2026 [Page]
Workgroup:
NMOP
Internet-Draft:
draft-henderickx-meta-graph-schema-01
Published:
Intended Status:
Standards Track
Expires:
Author:
W. Henderickx, Ed.
Nokia

Graph based Meta Schema for collaborative Operations

Abstract

Graph based Meta Schema for collaborative Operation

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 6 May 2026.

▲

Table of Contents

1. Introduction

Modern automation environments require systems, users, and agents to operate on shared data models in a coordinated manner. These models span heterogeneous technologies and administrative domains. Existing approaches such as YANG, OpenAPI, JSON Schema , ...primarily define the syntax and validation of data, but provide limited mechanisms for collaboration, coordination, and conflict-aware operations across multiple actors.

The Graph-based Meta Schema introduces a unified abstraction that models resources and their relationships as a knowledge graph, connecting data, intent, and operational context. This knowledge graph enables multi-actor automation, where humans, controllers, and services operate on a shared schema using common semantics and consistent operations.

This document defines three complementary elements:

This mechanism does not replace existing modeling languages; rather, it defines a meta-layer that integrates them and standardizes how resources and relations are described, linked, and managed.

2. Goals and Scope

The goal of the Graph-based Meta Schema is to define a generalized mechanism for describing and managing resources through a graph abstraction, and to standardize the operational semantics required for multi-actor collaboration.

Design principles:

3. Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

4. Conceptual Model

The Meta Schema distinguishes between resources (nodes) and relationships (edges):

This separation of what (resource) and how (relationship) enables the construction of a knowledge graph that links system intent, configuration, and operational context.

      +------------+
      |  Resource  |  (YANG, JSONSchema,…)
      +------------+
             |
             |  (Relationship / Edge)
             v
      +------------+
      |  Resource  | (YANG, JSONSchema,…)
      +------------+

5. Meta Schema

The Meta Schema provides a structural and semantic layer that integrates existing modeling frameworks (e.g., YANG, OpenAPI, JSON Schema) under a unified model.

The Meta Schema defines:

  1. Graph Topology – how resources are linked via typed relations and its constraints.
  2. Schema Semantics – how attributes, lists, and maps are defined, including types, constraints and validation rules.
  3. Operational Semantics – how API operations (create, update, delete, apply, watch, etc.) interact with resource state.
  4. User Semantics – how metadata supports visualization, grouping, and human-friendly interaction (e.g., labels, icons, colors, categories).

This integration allows a single schema definition to be reused across API servers, UI frameworks, and automation agents/workflows.

6. Graph based schema

The graph model treats each resource as a Node and each relationship as an Edge. Relationships MUST specify direction and type, and MAY include additional attributes/constraints (e.g., cardinality, constraints, requiredness).

Example relations include:

Each node carries structured metadata such as labels, annotations, status, and version, allowing tools to reason about topology, impact, and dependency chains in a consistent way.

7. API Operations

The Meta Schema defines conventions for API operations acting on resources. These conventions enable consistent behavior across REST, GraphQL, and streaming interfaces.

Each operation relies on metadata carried in the Meta Header. For example, server-side apply uses managedFields to detect and resolve conflicts; finalizers govern coordinated deletion; version identifiers (generation, resourceVersion) support optimistic concurrency; and relationships/ownership guide cascading behavior.

The standardized operations include:

8. Meta Header

Each resource includes a Meta Header, a standardized metadata structure that enables coordination between multiple actors and automation systems. The Meta Header provides a consistent mechanism for storing structural, operational, and user metadata alongside the resource specification.

The Meta Header MUST include the following conceptual components:

9. Example resource instance including meta header 

  apiVersion: assets.kuid.dev/v1
  kind: Device
  metadata:
    uid: "c9e1f3d1-7f27-4a1b-9f0f-2c9a1b6f7a42"
    name: router1
    tenant: default
    creationTimestamp: "2025-10-31T12:34:56Z"
    # deletionTimestamp is absent until deletion is requested
    resourceVersion: "7"
    generation: 3
    labels:
      purpose: core
    annotations:
      c4o.dev/displayName: "Router-1"
    relationships:
      - name: site
        target:
          group: location.kuid.dev
          version: v1
          kind: Site
          name: site-paris
          tenant: default
    finalizers:
      - cleanup.c4o.dev
    managedFields:
      - manager: controller.network
        operation: Apply
        fields: [ "spec.interfaces", "spec.routing" ]
  data: <YANG, ...>

10. Example schema 

apiVersion: apiextensions.c4o.dev/v1
kind: Schema
metadata:
    name: devices.assets.kuid.dev
spec:
    groups:
    - name: assets.kuid.dev
        apis:
        - resource: devices
          kind: Device
          scope: tenant
          ui:
            categories:
            - assets
            - devices
            displayName: Devices
            icon: xxx
            order: 100
          versions:
          - name: v1
            storage: true
            attributes:
            - # YANG, OpenAPI, JSONSchema, ...
            relationships:
            - name: belongsTo
              target:
                group: location.kuid.dev
                version: v1
                kind: Site
              cardinality: one
            - name: locatedIn
              target:
                group: assets.kuid.dev
                version: v1
                kind: Rack
              cardinality: one

Device - (belongsTo) - Site Device - (locatedIn) - Rack

11. IANA Considerations

This document has no IANA actions at this time.

12. Security Considerations

Schema definitions can expose sensitive structure and metadata about a system. Implementations MUST ensure that access control and data filtering mechanisms prevent unauthorized disclosure. Field ownership and event streaming MUST be authenticated and authorized according to the system’s security model.

13. References

Acknowledgements

The author thanks colleagues and contributors from the network automation and kubenet community for discussions leading to this work.

Authors' Addresses

Wim Henderickx Nokia 50 Copernicuslaan 2018, Antwerp Belgium

Email: wim.henderickx@nokia.com