An Intent Translation Framework for Internet of Things

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 25 December 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

The rapid growth of Internet of Things (IoT) deployments and the evolution toward 6G networks have introduced increasing complexity in the management of heterogeneous devices, services, and application policies. As operational environments scale, the traditional model of manually configuring service-level policies becomes unsustainable.¶

Intent-based management is a paradigm that allows administrators to specify desired outcomes through high-level intents, often expressed in natural language [Survey-IBN-CST-2023], [USENIX-ATC-Lumi], [I-D.jeong-nmrg-ibn-network-management-automation]. These intents must then be interpreted, validated, and translated into structured policy representations that can be executed by network functions and orchestrators. Recent work has explored the use of large language models for this translation step [Mekrache-IBN]. While standards such as 3GPP TS 28.312 [TS-28.312] define lifecycle procedures and an OpenAPI schema for managing intents in mobile networks and TR 28.812 [TR-28.812] describes the scenarios that motivate them, they do not specify mechanisms for interpreting natural language or translating it into compliant policy structures.¶

A central difficulty observed in recent industry benchmarks [GSMA-TeleYAML] is the so-called structural-semantic gap: a policy document may be syntactically valid against the schema while still being semantically incoherent across slots (for example, declaring an object type that is incompatible with the chosen target metric). Linguistic proficiency of a language model alone is insufficient to close this gap; standards-grounded structural constraints and post-generation validation are also required.¶

This document defines a modular intent translation framework that addresses this gap. The framework enables automated conversion of user-issued intents into structured policy representations, for example serialized as YAML or JSON, derived from the policy modeling and management service interfaces defined in 3GPP TS 28.312 [TS-28.312]. It supports a range of use cases across IoT domains, including resource optimization, security management, and service quality assurance.¶

The framework is composed of four functional components that operate in a partially parallel pipeline, plus a deterministic merge step and a feedback router:¶

• Scenario Extractor: Classifies the input intent along two axes - the management role (e.g., service customer, service provider, or network operator) and the deployment scenario (e.g., radio network, radio service, edge service support, or 5G core network) - producing a coordinate that routes downstream processing.¶

• Slot Extractor: Extracts entities and structured slot values (such as target name, target value, target unit, and target condition) from the same natural language input, in parallel with the Scenario Extractor.¶

• Intent Composer: Merges the outputs of the two Extractors into a single structured intermediate representation that the Policy Generator consumes.¶

• Policy Generator: Synthesizes a candidate policy document, typically serialized as YAML or JSON, under schema-as-grammar constraints derived from the target schema.¶

• Policy Validator: Evaluates the candidate policy along three dimensions - schema validity, cross-slot semantic invariants, and semantic faithfulness to the original natural language input - and produces a failure-mode trace when violations occur.¶

A trace driven recovery agent consumes the validator's failure-mode trace and dispatches targeted regeneration to the appropriate upstream component, rather than performing generic retry. The design promotes modularity, transparency, and alignment with existing network automation architectures, enabling consistent translation of operator goals into policies that are interoperable with standard orchestration and management systems in IoT environments.¶

2. Terminology

This document uses the terminology defined in [RFC9315], [RFC8329], [I-D.ietf-i2nsf-applicability], [I-D.jeong-nmrg-security-management-automation], and [SPT].¶

In addition, the following terms are defined for the purpose of this document:¶

• Intent: A set of operational goals (that a network should meet) and outcomes (that a network is supposed to deliver), defined in a declarative manner without specifying how to achieve or implement them [RFC9315].¶

• Intent-Based Management (IBM): It enforces an intent from a user (or administrator) into a target system. An intent can be expressed as a natural language sentence and translated into a high-level policy using natural language interpretation and structured policy mapping [I-D.jeong-nmrg-security-management-automation], [SPT]. This high-level policy is then transformed into low-level policies that are dispatched to appropriate Service Functions (SFs). Based on monitoring feedback, new rules may be generated or existing policies refined.¶

• Scenario Extractor: A logical function that receives a natural language input from the user or operator and classifies it along two axes: the management role (e.g., Communication Service Customer, Communication Service Provider, or Network Operator, as defined in 3GPP [TS-28.530]) and the deployment scenario (e.g., RadioNetwork, RadioService, EdgeServiceSupport, or 5GCNetwork, corresponding to the IntentExpectation subclasses defined in 3GPP [TS-28.312]). The output is a coordinate that constrains downstream component behavior.¶

• Slot Extractor: A logical function that, in parallel with the Scenario Extractor and given the same natural language input, extracts named entities and structured slot values (such as target name, target value, target unit, and target condition) required to populate the policy document.¶

• Intent Composer: A logical function that merges the outputs of the Scenario Extractor and the Slot Extractor into a single structured intermediate representation (typically a JSON document) consumed by the Policy Generator. The Intent Composer is a deterministic, schema-shaped aggregation step and does not itself perform language understanding.¶

• Policy Generator: A logical function that produces a machine-readable policy document, typically in a format such as YAML or JSON, from the merged outputs of the Scenario Extractor and the Slot Extractor. The Policy Generator operates under schema-as-grammar constraints that constrain per-token decoding against the target schema, such as that defined in 3GPP [TS-28.312].¶

• Policy Validator: A logical function that evaluates a candidate policy document along three dimensions: (i) schema validity against the OpenAPI specification of the target standard, (ii) cross-slot semantic invariants such as the relation between object type and target name, and (iii) semantic faithfulness between the original natural language intent and the candidate policy. The Policy Validator emits a failure-mode trace identifying which dimension(s), if any, were violated.¶

• Trace driven recovery agent: A logical function that consumes the failure-mode trace produced by the Policy Validator and dispatches targeted regeneration to the appropriate upstream component, rather than performing generic retry. The trace driven recovery agent supports failure-mode-specific corrective actions, such as regenerating the policy under additional structural constraints when a cross-slot violation is detected.¶

• Policy Knowledge Base: A repository that maintains domain-specific knowledge used during translation, including the schema of the target standard, examples of valid policy documents (such as those provided in informative annexes of 3GPP [TS-28.312]), and the relational invariants between schema fields (such as the mapping from object type to the set of valid target names). The Policy Knowledge Base supports schema-as-grammar compilation, few-shot retrieval, and cross-slot constraint checking.¶

• Schema-as-Grammar: A constrained-decoding technique that compiles a target schema (such as an OpenAPI specification or a JSON Schema) into a schema-derived grammar consumed by a language model decoder, so that each token continuation is constrained to keep the partial output extendable to a schema-admissible completion [Outlines][XGrammar][GCD][JSONSchemaBench]. The expressiveness of this grammar depends on the constrained-decoding implementation; not all schema features are expressible as efficient grammars, and post-generation validation is therefore still necessary. Schema-as-grammar may be applied at multiple levels, including the intermediate JSON representation produced by the Extractors and the candidate policy document produced by the Policy Generator.¶

• Failure Modes: Four orthogonal categories of failure observed in intent-to-policy translation: (i) F-syn, syntactic invalidity against the schema; (ii) F-sem, semantic mis-grounding such as selection of an invalid schema branch; (iii) F-val, value-range or unit errors in extracted slot values; and (iv) F-xs, cross-slot inconsistency in which individually valid fields combine to violate a relational invariant. Each failure mode is primarily detected by a designated component of the Policy Validator, though some categories (notably F-val) may be observed by more than one sub-component depending on whether the violation is expressible at the schema level or only with respect to the natural language context.¶

• Degraded Intent: An intent translation result that has been flagged as low-confidence because one or more failure modes could not be resolved within the configured retry budget of the trace driven recovery agent. A degraded intent may still result in policy generation, but with warnings or limited scope, and is suitable for routing to a human operator or to a validation pipeline before deployment.¶

3. Intent Translator Framework Architecture

This section defines the architecture of the Intent Translator Framework, which is designed to convert high-level, natural language intents into machine-readable policy representations in structured formats such as YAML. The framework enables intent-based management automation for IoT environments and aligns with policy modeling and lifecycle procedures defined in [TS-28.312].¶

                  +----------+
                  | IBN User |
                  +----------+
                       |
                       | natural language intent
                       v
 +--------------------------------------------------------------+
 |                                            Intent Translator |
 |                                                              |
 |   +---------------------+      +---------------------+       |
 |   |  Scenario Extractor |      |   Slot Extractor    |       |
 |   +---------------------+      +---------------------+       |
 |              |                            |                  |
 |              |    (parallel inference)    |                  |
 |              +-------------+--------------+                  |
 |                            |                                 |
 |                            v                                 |
 |                 +---------------------+                      |
 |                 |   Intent Composer   |                      |
 |                 +---------------------+                      |
 |                            |                                 |
 |                            v                                 |
 |                 +---------------------+  +----------------+  |
 |                 |  Policy Generator   |<-|      Policy    |  |
 |                 +---------------------+  | Knowledeg Base |  |
 |                            |             +----------------+  |
 |                            v                                 |
 |                 +---------------------+                      |
 |                 |  Policy Validator   |                      |
 |                 +---------------------+                      |
 |                            |                                 |
 |             pass           |       fail (with trace)         |
 |               +------------+------------+                    |
 |               |                         v                    |
 |               |               +-------------------+          |
 |               |               |  Trace driven     |          |
 |               |               |  recovery agent   |          |
 |               |               +-------------------+          |
 |               |                         |                    |
 |               |                         v                    |
 |               |                  targeted retry              |
 +---------------|----------------------------------------------+
                 v
          Validated YAML
          policy document

                  Natural Language Intent
                            |
              +-------------+-------------+
              |                           |
              v                           v
    +--------------------+     +--------------------+
    | Scenario Extractor |     |   Slot Extractor   |
    +--------------------+     +--------------------+
              |                           |
              v                           v
       {role, scenario}        {entities, slot values}
              |                           |
              +-------------+-------------+
                            |
                            v
                  +-------------------+
                  |  Intent Composer  |
                  +-------------------+
                            |
                            v
                     Policy Generator

        +---------------------+
        |   Intent Composer   |
        +----------+----------+
                   |
                   | Intermediate representation
                   v
    +-----------------------------+
    |            Policy Generator |
    |                             |
    |   +--------------------+    |   +----------------+
    |   |  Grammar Compiler  |<---|---| Policy         |
    |   +--------------------+    |   | Knowledge Base |
    |              |              |   +--------=-------+
    |              v              |
    |   +---------------------+   |
    |   | Constrained Decoder |   |
    |   +---------------------+   |
    +--------------+--------------+
                   |
                   | Candidate policy representation
                   v
            Policy Validator

             +---------------------+
             |  Policy Generator   |
             +----------+----------+
                        |
                        | candidate policy
                        v
   +-----------------------------------------+
   |                        Policy Validator |
   |                                         |
   |    +-------------------------------+    |
   |    |       Schema Validator        |    |
   |    |        (schema shape)         |    |
   |    +---------------+---------------+    |
   |                    |                    |
   |                    v                    |
   |    +-------------------------------+    |
   |    |       Semantic Solver         |    |
   |    |        (cross-slot)           |    |
   |    +---------------+---------------+    |
   |                    |                    |
   |                    v                    |
   |    +-------------------------------+    |
   |    |       Semantic Judge          |    |
   |    |     (intent faithfulness)     |    |
   |    +---------------+---------------+    |
   |                    |                    |
   +--------------------+--------------------+
                        |
                        v
             { pass | failure trace }
                        |
              +---------+---------+
              |                   |
        pass  |                   | fail + trace
              |                   v
              |           +----------------+
              |           | Trace driven   |
              |           | recovery agent |
              v           +----------------+
        Validated policy

4. IANA Considerations

This document does not require any IANA actions.¶

5. Deployment Considerations

The deployment of the Intent Translator Framework requires alignment between the Policy Knowledge Base and the operational policies supported by the underlying infrastructure. The schema of the target standard, examples of valid policy documents, and the relational invariants between schema fields must be encoded within the Policy Knowledge Base so that schema-as-grammar enforcement, few-shot retrieval, and cross-slot validation are consistent with the deployment environment.¶

Operators should validate the framework against representative intents and reference policies before enabling full automation. In particular, the routing table of the trace driven recovery agent should be calibrated using local failure traces and operational policy. The default routing policy described in Section 3.5 is a starting point and may need to be adjusted based on deployment data.¶

The computational requirements depend on the selected language models, constrained decoder, and validator implementation. Inference for the two Extractors and the Policy Generator can be served from a small number of accelerators when the underlying language models are of moderate size. The Schema Validator and the Semantic Solver are deterministic and inexpensive. The Semantic Judge, when realized as a language model, dominates the validator's computational cost, and may be replaced or supplemented by deterministic checks in latency-sensitive deployments. When the framework is deployed in a 5G system context [TS-23.501], the resulting policy documents are consumed by the Intent Driven Management Service (IDM-MnS) defined in [TS-28.312].¶

6. Extensibility Considerations

The modular architecture of the framework allows individual components - such as the Scenario Extractor, the Slot Extractor, the Policy Generator, or any sub-component of the Policy Validator - to be adapted to different domains, languages, or knowledge representations. As such, implementers can substitute the language model, modify the schema-as-grammar specification, or replace the output schema (e.g., YAML, XML, JSON) without altering the end-to-end pipeline.¶

The framework is designed to reduce coupling to a specific schema version. The schema-as-grammar specification consumed by the Policy Generator is compiled from the canonical OpenAPI specification of the target release, so that schema evolution between 3GPP releases can be accommodated by recompilation without changes to the pipeline. Forward compatibility with future releases of [TS-28.312] (such as Release 20) is intended through this design choice.¶

The Policy Knowledge Base may be extended over time with new examples, new entity types, and new relational invariants to support evolving service capabilities. Such extensions should preserve backward compatibility by maintaining stable identifiers for core operational concepts.¶

7. Degradation and Human Oversight Considerations

The framework supports degraded intent resolution through the bounded retry budget of the trace driven recovery agent. When the budget is exhausted without successful validation, the framework emits a degraded intent that records the residual failure mode and the most recent candidate policy. While this enables flexible operation in the presence of ambiguous intents or schema evolution, operators should evaluate how degraded intents are handled within their intent lifecycle.¶

For high-assurance environments, degraded intents should be reviewed by a human operator or routed to a validation pipeline before policy deployment. Logging mechanisms should be used to record degraded cases, the residual failure modes, and their resolution outcomes, so that future iterations of the Policy Knowledge Base, the routing table, and any supervised specialization of the Policy Generator can incorporate the observed cases.¶

Because the Semantic Judge has inherent calibration limits, deployments should treat F-sem-only failures with care. In some deployments it may be appropriate to accept the candidate policy when only F-sem is flagged but the Schema Validator and the Semantic Solver both pass, while logging the F-sem warning for later review.¶

8. Security Considerations

The Intent Translation Framework must operate over authenticated and confidential channels (e.g., TLS/HTTPS) to prevent eavesdropping, message tampering, or replay attacks by malicious actors. Implementations should enforce strict certificate validation and regularly rotate cryptographic keys to maintain transport-layer security.¶

Because the system processes free-form natural language intents, it is vulnerable to adversarially crafted inputs designed to produce unintended or harmful policies. Schema-as-grammar enforcement bounds the space of syntactically possible outputs, and the cross-slot Semantic Solver bounds the space of structurally coherent outputs, but neither prevents an adversary from issuing a semantically harmful intent that is nonetheless schema-valid and cross-slot coherent. Deployments should incorporate input validation, semantic sanity checks, and confirmation interfaces for high-impact operations, and should rate-limit or quarantine suspicious requests for manual review.¶

Deployments that use language-model components should also consider prompt-injection and instruction-confusion attacks. Inputs, retrieved examples, and schema descriptions should be separated by clear trust boundaries, and implementations should avoid allowing user-provided text to override validator, authorization, or deployment policies.¶

Policy generation should be bound to an authorization model. A policy that is schema-valid and semantically faithful to an input intent may still exceed the authority of the requesting principal or may have an unacceptable operational blast radius. High-impact candidate policies should therefore be subject to approval, rollback, and audit procedures before enforcement.¶

Intent collisions, in which contradictory or overlapping intents are submitted concurrently, can lead to policy conflicts or enforcement gaps. The framework must include conflict-detection logic that examines the relations between successive policy documents, and either automatically resolves detected collisions using a documented precedence model or escalates them to human operators for arbitration.¶

When the Policy Generator is specialized through supervised adaptation, the training corpus must be protected against poisoning. An adversary that injects malicious intent-policy pairs into the training corpus could bias the Policy Generator toward emitting policies that are schema-valid but operationally harmful. Implementations should record the provenance of each training example and should validate that supervised adaptation does not regress the framework's behavior on a held-out test set of known-good intents.¶

9. Implementation Status

This section is included to provide an indication of implementation status, consistent with [RFC7942]. It does not constitute an endorsement by the IETF or the IRTF, and it is expected to be removed or updated before publication as an RFC.¶

A research prototype of the framework has been exercised using publicly available components: an open-weight language model for the Extractors and Policy Generator, a constrained-decoding engine for schema-derived generation constraints, a JSON Schema validator for schema-level checks, and an SMT solver for selected cross-slot invariants. The prototype used the OpenAPI specification of 3GPP TS 28.312 (as of Release 19) as the target schema source.¶

Preliminary experiments were performed on a small synthesized data set of natural language intents and reference policy representations, derived from the OpenAPI schema via template-based synthesis and augmented by paraphrastic methods. The experiments were used to compare a single-extractor baseline with the parallel-extractor and validation-routing design described in this document. The observations suggest that parallel extraction and cross-slot validation reduce several classes of residual errors, especially cross-slot inconsistency. These results are preliminary and do not constitute a generalization claim; the data set and evaluation harness are not yet sufficient for that purpose.¶

A future revision is expected to identify the prototype repository, the data set generation method, the exact schema version, and the evaluation harness once those artifacts are made publicly available.¶

Appendix B. Contributors

This document has greatly benefited from inputs and discussions within the IRTF Network Management Research Group (NMRG), with contributions from Yong-Geun Hong (Daejeon University) and Joo-Sang Youn (Dong-Eui University). The authors sincerely appreciate their contributions.¶

The following are coauthors of this document:¶

Authors' Addresses