Framework for Normalizing Multi-Vendor Network Inputs for LLM-Assisted Network Management
draft-prabhu-nmrg-prompt-schema-llm-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Shailesh Prabhu | ||
| Last updated | 2026-10-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-prabhu-nmrg-prompt-schema-llm-01
Network Working Group S. Prabhu
Internet-Draft Nokia
Intended status: Informational 4 October 2026
Expires: 7 April 2027
Framework for Normalizing Multi-Vendor Network Inputs for LLM-Assisted
Network Management
draft-prabhu-nmrg-prompt-schema-llm-01
Abstract
Large Language Models (LLMs) are increasingly used to assist network
management tasks such as troubleshooting, intent translation, and
automation. Network operations, however, rely on data from many
vendors and sources: CLI output, configuration snippets, telemetry,
alarms, and vendor-specific APIs. These inputs differ in format,
structure, and semantics, which makes it difficult to present a
consistent interface to an LLM. This document describes a framework
for standardizing such multi-vendor inputs for LLM-assisted network
management. Incoming messages from multi-vendor network elements are
first handled by an Input Classifier, which determines the nature of
each input and assigns it to one of three categories: performance,
configuration, or response, using a hybrid approach (rule-based
classification first, with escalation to a Small Language Model (SLM)
when rules are insufficient). The classified input is then passed to
the corresponding Structurer among the Performance Structurer,
Configuration Structurer, and Response Structurer, each of which
produces a normalized, structured representation (typically with SLM
assistance and optional confidence scoring). That structured output
is fed to a Prompt Schema Generator, which creates a structured,
vendor-agnostic schema and supplies schema-aligned prompts to the
central LLM. This document specifies the architecture and component
roles for use in design and implementation. It does not define a
wire protocol; it is published for informational purposes.
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/.
Prabhu Expires 7 April 2027 [Page 1]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
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 7 April 2027.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 5
3.1. Architectural Placement and Interfaces . . . . . . . . . 6
4. Input Classifier . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Rule-based classification . . . . . . . . . . . . . . . . 8
4.1.1. Performance message detection . . . . . . . . . . . . 8
4.1.2. Configuration message detection . . . . . . . . . . . 9
4.1.3. Response message detection . . . . . . . . . . . . . 9
4.2. SLM-based classification . . . . . . . . . . . . . . . . 9
5. Structurers . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Semantic Normalization . . . . . . . . . . . . . . . . . 10
5.2. Performance Structurer . . . . . . . . . . . . . . . . . 10
5.3. Configuration Structurer . . . . . . . . . . . . . . . . 11
5.4. Response Structurer . . . . . . . . . . . . . . . . . . . 12
6. Prompt Schema Generator . . . . . . . . . . . . . . . . . . . 13
7. Output and Downstream Use . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
Prabhu Expires 7 April 2027 [Page 2]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
1. Introduction
LLM-assisted network management uses Large Language Models to
interpret network data, suggest actions, translate operator intent
into device commands, and assist with root cause analysis and
reporting. The effectiveness of such systems depends on the quality
and consistency of the inputs presented to the LLM. In practice,
those inputs are highly heterogeneous: show-command output and
configuration dumps vary by vendor and device type; telemetry and
alarms use different formats and naming; and management APIs differ
across vendors. Without normalization, the same logical concept
(e.g., "interface status" or "BGP neighbor state") appears in many
forms, which degrades LLM performance and complicates prompt design
and maintenance.
This document describes an architectural framework for standardizing
multi-vendor inputs before they are used as prompts (or prompt
context) for a central LLM in network management. The flow is as
follows. (1) Multi-vendor network data is received by the Input
Classifier, which classifies each message as performance-related,
configuration-related, or response-related so that the appropriate
Structurer receives the right type of input. The Input Classifier
uses a hybrid approach: a fast, deterministic rule-based stage first;
when pattern matching fails, multiple category conflicts arise, or
structural certainty is insufficient, an SLM-based classification
stage within the Input Classifier is invoked. (2) Based on that
classification, the message is passed to exactly one of the
Performance Structurer, Configuration Structurer, or Response
Structurer, each of which interprets vendor-variable text and emits a
structured record. (3) The structured output is fed to the Prompt
Schema Generator, which creates or selects a vendor-agnostic schema
and produces schema-aligned prompts. (4) Those prompts are supplied
to the central LLM that performs network management (e.g.,
troubleshooting, intent translation, or automation).
The framework is complementary to broader work on AI-assisted and
agent-based network management. While such work may address agent
interaction, orchestration, tool access, or operational workflows,
this document focuses specifically on normalizing heterogeneous
network management inputs before they are consumed by an LLM. The
normalization function may therefore serve as an input-processing
building block within broader AI-assisted network management
architectures.
Prabhu Expires 7 April 2027 [Page 3]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
The key components are the Input Classifier, the three Structurers,
the Prompt Schema Generator, and the central LLM. Together, they
enable multi-vendor inputs to be categorized, structured, normalized,
aligned with a vendor-agnostic schema, and presented to the central
LLM in a consistent form.
2. Terminology
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.
* LLM (Large Language Model): A machine learning model used for
natural language understanding and generation. In this document,
the LLM is the consumer of standardized network management inputs
for tasks such as troubleshooting, intent translation, and
automation.
* Prompt: Input (or input context) supplied to an LLM for
processing. In LLM-assisted network management, a prompt
typically includes network-derived data such as CLI output,
configuration snippets, telemetry, or alarms, often after
normalization and alignment with a vendor-agnostic schema.
* Schema: A formal, vendor-agnostic description of the structure,
types, and semantics of a class of network management inputs. A
schema provides a common shape to which normalized multi-vendor
data can be aligned before being presented to the LLM.
* Input Classifier: A component that determines the nature of
incoming messages from multi-vendor network elements and assigns
each input to one of three categories: performance, configuration,
or response, so that the corresponding Structurer can process it.
It uses a hybrid rule-based stage followed by SLM-based
classification when the rule-based stage is inconclusive.
* Structurer: A component that receives input already labeled by the
Input Classifier with one category and produces a structured,
normalized representation for the Prompt Schema Generator. This
document defines three structurers: Performance Structurer,
Configuration Structurer, and Response Structurer.
Prabhu Expires 7 April 2027 [Page 4]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
* Small Language Model (SLM): A compact language model used inside
the Input Classifier (for semantic classification when rules fail)
and inside each Structurer (for extraction, normalization, and
confidence). SLMs MAY be fine-tuned on curated multi-vendor
network messages, telemetry, configuration text, and operational
responses.
* Confidence level: An optional indicator (e.g., high, medium, low)
associated with structuring or classification. Low-confidence
cases MAY attach raw input for human-in-the-loop review and later
feedback into training of the Input Classifier and Structurers.
3. Architecture Overview
The framework is a logical system positioned between heterogeneous
multi-vendor network management data sources and a central LLM used
for AI-assisted network management. Raw inputs (e.g., CLI output,
configuration, telemetry, alarms, or API responses) enter the Input
Classifier. The classifier routes each message to the Performance
Structurer, Configuration Structurer, or Response Structurer. The
active Structurer's output is fed to the Prompt Schema Generator,
which produces schema-aligned prompts or prompt context for the
central LLM. The architectural placement of these functions and the
logical interfaces between them are described in Section 3.1.
Prabhu Expires 7 April 2027 [Page 5]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
+---------------------------+
| Central LLM |
| (network management: |
| troubleshooting, |
| intent translation, |
| automation) |
+-------------+-------------+
^
| schema + prompts
+-------------------+
| Prompt Schema |
| Generator |
+---------+---------+
^
| structured output
+-----------------+-----------------+
| | |
+-------+-------+ +-------+-------+ +-------+-------+
| Performance | | Configuration | | Response |
| Structurer | | Structurer | | Structurer |
+-------+-------+ +-------+-------+ +-------+-------+
^ ^ ^
+-----------------+-----------------+
|
+---------+---------+
| Input |
| Classifier |
| (rules + SLM) |
+---------+---------+
^
|
+-------------------------+-------------------------+
| Multi-Vendor Network Input |
| (CLI, config, telemetry, alarms, vendor APIs) |
+---------------------------------------------------+
Figure 1: Reference architecture
3.1. Architectural Placement and Interfaces
The framework is logically positioned within, or adjacent to, a
Network Management System (NMS), controller, or orchestrator, between
network data acquisition functions and the central LLM. Existing
mechanisms may continue to collect CLI output, telemetry,
configuration, alarms, or vendor API responses; the framework does
not require changes to the network elements or the mechanisms used to
acquire such data.
Prabhu Expires 7 April 2027 [Page 6]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
The interfaces between the framework components are logical. Raw
network input is provided to the Input Classifier, which assigns an
input category and forwards the input to the corresponding
Structurer. The selected Structurer produces a normalized structured
representation for the Prompt Schema Generator, together with
metadata such as the assigned category and confidence information;
the original input may also be retained for traceability in low-
confidence cases. The Prompt Schema Generator uses the normalized
representation to produce schema-aligned prompt content for the
central LLM.
These interfaces do not require a specific transport protocol or
serialization format. Implementations may use JSON, YANG-derived
structures, or other structured encodings for the normalized
representation, while the LLM-facing output may be provided as prompt
text or structured prompt context. This document does not define a
wire protocol for these interfaces.
While this document focuses on normalizing multi-vendor network
management inputs for consumption by a central LLM, the normalization
function could also be applicable to interactions between an AI agent
and an NMS, or between management agents using heterogeneous
representations. Such uses are outside the primary scope of this
document but may be considered in future work on agent-based network
management.
4. Input Classifier
The Input Classifier is responsible for determining the nature of
incoming messages from multi-vendor network elements. It assesses
each input and classifies it into exactly one of three categories:
performance, configuration, or response, so that the corresponding
Structurer receives the appropriate type of input for further
processing.
The Input Classifier uses a hybrid approach: rule-based
classification is attempted first, followed by SLM-based
classification when the rule-based stage cannot produce a reliable
single category. The hybrid design balances speed, efficiency, and
accuracy: rule-based logic is fast and lightweight for common
patterns; when inputs are complex, ambiguous, or unmatched by rules,
an SLM performs deeper contextual analysis.
Prabhu Expires 7 April 2027 [Page 7]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
4.1. Rule-based classification
In the first stage, the Input Classifier applies a deterministic,
rule-based mechanism to categorize incoming network element messages.
This layer is intended for high-frequency, well-structured, and
common message formats without invoking computationally intensive
semantic analysis.
The rule-based engine MAY use a combination of:
* Keyword dictionaries.
* Structured field detection.
* Regular expression matching.
* Protocol-aware parsing.
* Message header inspection.
Each message is evaluated against category-specific rule sets for
performance, configuration, and response classification.
4.1.1. Performance message detection
Performance-related messages typically describe operational metrics,
telemetry readings, utilization values, or statistical measurements.
Example keyword families include: utilization, throughput, latency,
jitter, packet loss, bandwidth, CPU usage, memory usage, temperature,
receive/transmit rates, error rate, and queue depth (exact
vocabularies are implementation defined).
Pattern-based heuristics MAY include: numeric values with percentage
signs; metric names adjacent to numeric measurements; telemetry-style
field-value formats. As an illustrative example, a regular
expression such as:
(utilization|load|usage)\s*[:=]?\s*\d+(\.\d+)?\s*%
can match lines such as "CPU utilization: 78%", "Traffic load = 45%",
and "Network usage 62%". Similar patterns MAY be defined for other
performance metrics (e.g., latency, throughput).
Prabhu Expires 7 April 2027 [Page 8]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
4.1.2. Configuration message detection
Configuration-related messages indicate intent to modify, retrieve,
delete, or update network state. Example keywords include: set,
configure, apply, update, modify, delete, add, remove, commit,
rollback, enable, and disable.
As an illustrative example, a regular expression such as:
(set|update|configure|modify)\s+(interface|vlan|route|policy|qos|ip)
can match phrases such as "Set interface Gi0/1 bandwidth 100Mbps",
"Update VLAN 10 configuration", and "Modify route table entry".
4.1.3. Response message detection
Response messages typically represent outcomes of prior operations.
Example keywords include: success, completed, applied, acknowledged,
error, failed, failure, invalid, timeout, rejected, and warning.
As an illustrative example, a regular expression such as:
(success|completed|applied|acknowledged)\b
can match phrases such as "Configuration applied successfully",
"Operation completed", and "Request acknowledged".
When pattern matching fails, multiple categories conflict, or
structural certainty is insufficient, implementations SHOULD escalate
to SLM-based classification within the Input Classifier.
4.2. SLM-based classification
When the rule-based stage cannot categorize a message (for example,
due to absence of rule matches, conflicting rule matches, or
ambiguous structure), the message is processed by an SLM-based
semantic classification stage inside the Input Classifier.
The SLM interprets context, semantics, and structure to assign the
message to performance, configuration, or response. The model MAY be
trained or fine-tuned on a curated corpus that includes historical
multi-vendor network messages, telemetry logs, configuration
commands, and operational responses, so that nuanced and vendor-
specific formats can be handled using contextual cues (e.g.,
attention over token relationships and embeddings).
Prabhu Expires 7 April 2027 [Page 9]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
5. Structurers
After classification, the message is delivered to exactly one of
three Structurers. Each Structurer interprets inputs that the Input
Classifier has already labeled with the matching category. Because
vendors represent performance, configuration, and response text in
widely varying forms, each Structurer typically employs an SLM for
adaptability, extraction, normalization, and confidence assignment.
Structured records are then passed to the Prompt Schema Generator.
5.1. Semantic Normalization
A Structurer may need to reconcile vendor-specific terms, field
names, and representations that refer to the same network management
concept. For example, different vendors may represent the same
receive-error metric as "rx_errors", "input errors", or
"receive_errors". The Structurer maps such representations to a
common representation before passing the structured record to the
Prompt Schema Generator.
Implementations may perform this mapping using explicit mapping rules
or tables, controlled vocabularies or glossaries, semantic models or
ontologies, knowledge graphs, SLM-assisted semantic matching, or a
combination of these techniques. The choice of mechanism is
implementation specific. SLM-assisted mappings may additionally use
confidence information and human review, as described elsewhere in
this document, when the mapping is uncertain.
Determining which normalization techniques, or combinations of
techniques, are most suitable for heterogeneous network management
inputs is an area for further research. Relevant considerations
include mapping accuracy, semantic preservation, coverage of
previously unseen representations, explainability, extensibility, and
operational cost.
5.2. Performance Structurer
The Performance Structurer processes inputs categorized as
performance by the Input Classifier.
Typical processing steps include:
1. Input reception: The structurer receives performance-labeled
input (e.g., a line such as "Traffic load = 75%").
Prabhu Expires 7 April 2027 [Page 10]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
2. Value extraction: The SLM extracts numeric and unit information
(e.g., isolating "75" and "%"). Heterogeneous forms (e.g.,
ratios such as "8/10") MAY be converted to a comparable
representation (e.g., 80%).
3. Normalization: Values and units are normalized to a consistent
representation appropriate to the metric. For example,
equivalent ratios and percentages may be converted to a common
scale, while throughput or latency values may be converted to
consistent units.
4. Confidence scoring: The SLM MAY assign high (well-recognized
pattern), medium (ambiguous; flag for review), or low
(unrecognized pattern). For low confidence, implementations MAY
attach the raw network element input when sending output to the
Prompt Schema Generator for human-in-the-loop review; feedback
from that review MAY later be used to retrain or refine the Input
Classifier and Structurers.
5. Performance structuring: The structurer emits a structured
representation to the Prompt Schema Generator in an
implementation-defined format consistent with the chosen schema.
5.3. Configuration Structurer
The Configuration Structurer processes inputs categorized as
configuration by the Input Classifier.
Typical processing steps include:
1. Input reception: Configuration-labeled input is received (e.g.,
"Set interface bandwidth to 100 Mbps").
2. Operation identification: The SLM detects the configuration
operation (e.g., set, update, delete, enable, disable).
3. Target identification: The structurer identifies the
configuration target (e.g., interface bandwidth, firewall rule,
routing policy).
4. Value extraction: When present, parameter values are extracted
(e.g., "100 Mbps"); some operations (e.g., "enable logging") MAY
have no separate value beyond the operation and target.
5. Normalization of targets: Vendor-specific phrases for the same
concept (e.g., "interface bandwidth" vs. "link speed") are mapped
to a standard target representation.
Prabhu Expires 7 April 2027 [Page 11]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
6. Configuration structuring: A structured record is emitted to the
Prompt Schema Generator in an implementation-defined format
consistent with the chosen schema.
5.4. Response Structurer
The Response Structurer processes inputs categorized as response by
the Input Classifier, using an SLM to cope with variability in how
vendors phrase operational outcomes.
Typical processing steps include:
1. Input reception: Response-labeled input is received (e.g.,
"Configuration applied successfully on interface Gi0/1").
2. Response intent interpretation: The SLM determines the outcome
category, such as success, failure, partial success, warning,
timeout, or rejection; whether the message relates to a prior
configuration action; and whether an explicit error condition is
present.
3. Error and context extraction: For failure or warning outcomes,
the SLM MAY extract error reason, error code (if present),
parameters involved, and affected object (e.g., interface, route,
policy).
4. Confidence assignment: High confidence MAY correspond to clear
success/failure wording; medium to ambiguity; low to non-standard
or unclear outcomes; raw input MAY be attached for the Prompt
Schema Generator when confidence is low.
5. Response structuring: A standardized structured representation is
produced for the Prompt Schema Generator in an implementation-
defined format consistent with the chosen schema.
The three structurers are distinct logical components; for a given
message, only the structurer matching the Input Classifier's category
is used. Implementations MAY pipeline batches such that multiple
structured records are produced over time and assembled by the Prompt
Schema Generator according to policy.
Prabhu Expires 7 April 2027 [Page 12]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
6. Prompt Schema Generator
The Prompt Schema Generator receives structured output from the
active Structurer (performance, configuration, or response),
optionally including raw input attachments and confidence metadata
from low-confidence paths. It creates or selects a structured,
vendor-agnostic schema appropriate to that category and message
shape, and produces schema-aligned prompts for the central LLM.
Functions of the Prompt Schema Generator in this context include:
* Creating or selecting schemas that define structure, fields,
types, and semantics of network management inputs in a form
suitable for the central LLM, with schema choice driven by the
classification and structurer output.
* Aligning normalized structured representations with a selected
vendor-agnostic schema so the central LLM receives consistent
input regardless of source.
* Feeding the schema and resulting prompts (or prompt context) to
the central LLM for tasks such as troubleshooting, intent
translation, and automation.
Implementations may use static schema definitions (e.g., based on
common network management information models) or dynamically updated
schemas. The Prompt Schema Generator aligns the normalized
structured records produced by the Structurers with the selected
schema and constructs schema-conformant prompts or prompt context for
LLM invocation.
7. Output and Downstream Use
The output of the framework is schema-aligned prompts (or prompt
context) from the Prompt Schema Generator, derived from classified
and structured multi-vendor input. Each prompt is associated with
the performance, configuration, or response category assigned by the
Input Classifier, with the schema used to create it. These prompts
are supplied to the central LLM that performs network management
(e.g., troubleshooting, intent translation, compliance analysis, or
automation). Downstream components (e.g., prompt assembly, LLM
invocation, or result parsing) use the category, structurer output,
and schema alignment to choose models, templates, and response
handling. The exact format and semantics of data passed from the
Prompt Schema Generator to the central LLM are implementation
defined.
Prabhu Expires 7 April 2027 [Page 13]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
8. Security Considerations
The structure of this section is informed by the guidelines in
[RFC3552]. Implementations of this framework in LLM-assisted network
management should consider the following:
* Network management inputs often contain sensitive data:
credentials, topology, IP addressing, and configuration details.
Data flows through the Input Classifier, the active Structurer,
the Prompt Schema Generator, and the central LLM; each stage may
expose this information. Implementations SHOULD apply data
minimization (e.g., redacting or tokenizing secrets during
classification, structuring, and schema generation), secure
transport and storage for intermediate data, and policies that
limit what is sent to external or cloud-hosted LLMs. Compliance
with organizational and regulatory requirements for network and
personal data SHOULD be ensured.
* Schema definitions and mapping rules determine what structure and
fields are sent to the LLM. Schema generation or selection that
relies on untrusted input can introduce injection or policy bypass
risks. Implementations SHOULD validate and constrain schema
content and SHOULD restrict who can create or modify schema
definitions and vendor mappings.
* Incorrect classification or structuring can change which prompts
and schemas are used and can affect prioritization and access
control. Crafted inputs that are misclassified or misstructured
could lead to incorrect LLM behavior, privilege escalation, or
denial of service. Implementations SHOULD treat classifier and
structurer output as advisory where security is critical and
SHOULD apply additional checks before acting on LLM outputs that
affect network configuration or access.
* Consolidating multi-vendor inputs increases attack surface:
parsers, regex engines, SLM inference, schema mappings, and paths
to the central LLM. Implementations SHOULD harden the Input
Classifier, each Structurer, the Prompt Schema Generator, and any
normalizers against malformed or malicious input and SHOULD
monitor for abuse or unexpected classification patterns.
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
Prabhu Expires 7 April 2027 [Page 14]
Internet-Draft Normalizing MV Inputs for LLM NM October 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
10.2. Informative References
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/rfc/rfc3552>.
Author's Address
Shailesh Prabhu
Nokia
India
Email: shailesh.prabhu@nokia.com
Prabhu Expires 7 April 2027 [Page 15]