| Internet-Draft | Applicability of MCP for the Network Man | July 2026 |
| Yang, et al. | Expires 7 January 2027 | [Page] |
The application of MCP in the network management field is meant to refactor network management operation and network capabilities as tools and provide more agile and extensible architecture to expose these AI integration capabilities. This document discusses the applicability of MCP to the network management plane in the IP network that utilizes IETF technologies. It explores MCP for network exposure, multiple MCP server discovery, communication between Network Elements or between the Network element and the Network Controller/Network Gateway.¶
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 7 January 2027.¶
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.¶
The Model Context Protocol (MCP) decouples LLMs from tools and provides a standardized way for LLMs to access and utilize information from different data sources and tools, making it easier to build AI applications that can interact with external LLM models and software tools and enable workflows automation.¶
MCP has seen rapid adoption across both startups and enterprises since it was announced in November 2024. Key use cases include AI coding assistants in IDEs, data analysis tools that can query databases, and productivity tools that can interact with services like Slack or Google Drive.¶
The application of MCP for the network management is meant to refactor network management operation and network capabilities as tools and provide more agile and extensible architecture to expose or consume these AI integration capabilities.¶
With integration of MCP into the network management system, it allows you to develop various rich AI-driven network applications, realize intent based network management, automate workflows in the multi-vendor heterogeneous network platform. By establishing standard interfaces for tool encapsulation, intent translation, and closed-loop execution within the network management system, MCP enables the network management system to have:¶
Unified operation abstraction through normalized MCP tool definitions¶
Seamless LLM integration via the structured protocol¶
Automation Execution Ability¶
This document discusses the applicability of MCP to the network management plane in the IP network that utilizes IETF technologies. It explores MCP for network exposure, multiple MCP server discovery, communication between Network Elements or between the Network element and the Network Controller/Network Gateway.¶
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.¶
The following terms are used throughout this document:¶
MCP Protocol: MCP is an open standard designed to facilitate communication between LLMs and external data sources or tools.¶
MCP Host: The entity initiating the LLM request.¶
MCP Client: A built-in module within a host, specifically designed for interaction with the MCP server.¶
MCP Server: A dedicated server that interacts with MCP clients and provides tools.¶
CLI: Command Line Interface¶
+---------------+ +---------------+
| | | |
| 3rd Party | | 3rd-party
| AI Agent | | Tools/Contents|
+-----/---\-----+ +---------------+
| | | |
| | ----------------- \ /
/////// \\\\\\\
|| ||
|| ||
| MCP Eco-system |
|| ||
\\\\\\\ ///////
/ \ ----------------- | |
| | | |
+---------------+ +----- \---/----+
| | | |
| Network MCP | | In-Network |
| Server | | Service |
(network exposure) (e.g.,Digital assistant)
+---------------+ +---------------+
/ \ / \
| | | |
+------+---+-------------------+---+----+
| |
| Network Intelligence |
| |
| Agentic + MCP Architecture Paradigm |
| |
+---------------------------------------+
¶
There are 3 values for MCP coupling with the network management¶
Protocol Design¶
Error Handling¶
o Although MCP provides basic error codes, MCP does not yet enforce a entire error-handling mechanism, and its scope is currently limited to discovery and invocation, omitting crucial aspects like tool governance, versioning, or lifecycle management.¶
Stateful¶
o The protocol's reliance on stateful Server-Sent Events (SSE) can create significant complexities when integrating with inherently stateless REST APIs, requiring developers to manage state externally. This can be particularly challenging for remote MCP servers due to network latency and instability, complicating load balancing and horizontal scaling efforts.¶
Context Handling¶
o There are also concerns that multiple active MCP connections could consume significant tokens in the LLM's context window. This can directly impact an LLM's performance, slowing down responses and potentially hindering its ability to maintain focus and reason effectively over extended or complex interactions.¶
Security Consideration¶
Malicious Actors¶
The protocol's ability to grant LLMs access to external systems introduces potential vulnerabilities that require careful consideration¶
o Prompt injection, where malicious instructions embedded in user inputs or tool descriptions could lead to unintended actions by the LLM;¶
o Tool poisoning, where attackers modify tool definitions, or rug pulls (similar to tool poisoning but occurs post-installation);¶
o Tool shadowing, where a malicious server creates a tool with the same name as a legitimate tool from another server to intercept calls;¶
Security enforcement¶
o MCP itself lacks inherent security enforcement mechanisms, relying heavily on external implementations for authentication and authorization, which were not initially well-defined within the protocol.¶
Identity Management¶
o Determining clear identity management - whether requests originate from the end user, the AI agent, or a shared system account - remains an area needing clearer definition.¶
Network exposure is the process of making network capabilities, such as data and connectivity services, available to external users, applications, and developers through secure APIs. It allows for more agility and the creation of programmable networks. The MCP can be used to expose network capabilities to AI applications or consume external sources for LLMs.¶
3rd Party
+------------------+
| Consumer |
| +------------+ |
| | | | 4. Authoriz and Consume
| | MCP Client <-+------------------------+
+---+-+-------^--+-+ |
2.Discover |3. List of |
and Authz | Available APIs |
| | |
| | |
+---+-V-------+--+------------+ +---V--------+
| | MCP Server | | |Tools |
| +------------+ |1.Publish|+----------+|
| <---------+|Simulation||
| Network Exposure Agent | || API ||
| /Network Controller |4. Authz |+----------+|
| +---+ +---+ +---+ <---------> |
| |NF1| |NF2| |NF3| ... | |+----------+|
| +---+ +---+ +---+ | Heart ||Other APIs||
| <--------->+----------+|
+-----------------------------+ Beat +------------+
¶
Step 1: External tools or data source publish a set of APIs to MCP server in the Network Controller.¶
Step 2: MCP client sends a specific tool request to discover tools and MCP Server provides authorization to the MCP client.¶
Step 3: After successful authorization, MCP server returns the API list corresponding to the tool request sent by the MCP client.¶
Step 4: MCP Client invokes tools with authorization.¶
+---------------+
| Data Source |
| +-----------+ |
| | MCP Server| |
+-+-----^-----+-+
|2. Consume external sources
|
+------+-----V-----+-----------+
| | MCP Client|0.Preconfig MCP
+--------------+ | +-----------+ Server Address
| IETF |1.MCP Service Request |
| Network +--------> |
| Management |3.MCP Service Response |
| AI Agents <--------+ |
+--------------+ | |
| Network Controller |
| |
+------------------------------+
¶
Step 0: MCP Client is preconfigured with the MCP Server address.¶
Step 1: IETF Network Management AI Agent sends a MCP Service Request to the MCP client within the Network Controller.¶
Step 2: The MCP client discovers tools provided by the external MCP server.¶
Step 3: The MCP client provides the available tools list to the IETF Network Management AI Agent.¶
The MCP Server Discovery involves clients querying servers to find available tools, resources, and functions. In case MCP servers are distributed in different locations, MCP Repository can be established to keep track of the location of each MCP servers.¶
+------------+ 2.Discovery ---------------+
| Agents +-----------+ MCP |
|(MCP Client)+-----------+ Repository |
+-+----------+ 3. Authz +--------^-------+
|4. Consume |1.Registration
| +-------------+---------------+-------+-
+----------V-+ +-----+-------+ +------+------+
|MCP Server 1| |MCP Server 2 | | MCP Server 3|
+------------+ +-------------+ +-------------+
------- ----- -----
///FM PM \\\ /// \\\ /// \\\
| | || Memory | || |
| Routing ACL| | | | Templates|
\\\Policy /// || Database | || |
------- \\\ /// \\\ ///
----- -----
¶
o MCP Repository: * Maintain the description of MCP servers * Support MCP server discovery for Client.¶
o MCP client: consuming the services provided by MCP servers¶
o MCP servers: including authentication/session/policy tools, the memory/prompts used for Agents¶
+------------------+ +----------+ +-------+ +------+
|Network Management| | | | | | |
| AI Agent | | MCP | | MCP | |Tools |
| (MCP Client) | |Repository| |Servers| | |
+---------+--------+ +----+-----+ +---+---+ +---+--+
| | | 0. Sync the info of tools
| | |<------------+
| |1. Registration |
| |<------------+ |
| | | |
| +-------------+----------+ | |
| | Repository | | |
| |MCP Server1:ID 1, Capability, Tools |
| | | | |
| |MCP Server2:ID 2, Capability, Tools |
| +------------- ----------+ | |
| 2.1 Discovery | | |
+------------------> | |
| +------+------+ | |
| | Search for | | |
| | Proper MCP | | |
| | Server | | |
+-------------+ | |
| 2.2 Address of MCP Server | |
<------------------+ | |
3. oAuth Authz | |
<------------------------------->| |
| 4. Consume Tools/Resources/Prompts |
+------------------+-------------|-------------|
| | |
¶
Step 0: The MCP Server syncs up on the info of tools, when tools are added or removed, tools changes will be automatically synced up with the MCP server.¶
Step 1: Each new MCP server will register to the centralized MCP registry.¶
Step 2.1: MCP Client sends the MCP service request to the MCP registry for specific capability.¶
Step 2.2: The MCP registry returns a specific MCP server to the MCP client.¶
Step 3: The MCP Client request authorization from the MCP server.¶
Step 4: The MCP Client invokes specific tools with authorization.¶
In MCP-based network management environments, exposed tools may represent operationally sensitive network management actions, including telemetry retrieval, diagnostics, configuration modification, service provisioning, policy updates, or device control operations. While the MCP repository maintains information about MCP servers, tools, and capabilities, additional network-management-specific capability metadata may improve operational safety, interoperability, and automated decision-making.¶
MCP repositories and MCP servers may associate tools with metadata describing both functional capabilities and operational constraints of the exposed capability as follows:¶
Functional capability metadata: operation type, operational scope, supported management protocols, rollback support capability, and operational risk level.¶
Operational constraint metadata authorization requirements, human approval requirements, freshness indicators, and synchronization version information.¶
Such metadata may assist MCP clients, AI agents, and orchestration systems in evaluating the suitability, applicability, and operational safety of MCP tools prior to authorization and invocation, particularly in large-scale distributed network management deployments.¶
This section describes MCP deployment requirements for network management environments, followed by implementation scenarios. Key architectural requirements include:¶
Function-Specific MCP Servers: To maintain proper architecture and performance with growing tool volumes, servers should be categorized by network management functions. Typical categories include network log analysis, device configuration management, energy consumption management, and security operations, etc.¶
Secure and Scalable Architecture: The architecture must:¶
Automated Workflows: MCP implementations should support LLM-coordinated automation of:¶
While these core requirements apply universally, operational characteristics vary based on deployment location. The following subsections detail these deployment scenarios.¶
In this network scenario, the MCP client is deployed in one smart network element while the MCP server is deployed in another smart network element. The MCP client communicates with the MCP server using the MCP protocol and invokes specific tools and gets access to specific data in the network element as a data source. In addition, human operator can use natural language to interact with smart network element to investigate protocol troubleshooting information.¶
Network elements usually have limited resources (CPU, memory, etc.). Deploying MCP Client together with SLM may occupy a large amount of resources, affecting the normal operation of the device.¶
Human Operator
|
|
Natural Language Data Source
+-----------+-------------+ +-------------------------+
| +-------+----------+ | | +------------------+ |
| |Routing Protocol | | | |Routing Protocol | |
| | Agent | | | | Agent | |
| |+---+ +----------+| | | | +----------+ | |
| ||SLM| |MCP Client++--+-----+---+->MCP Server| | |
| |+---+ +----------+| | | | +----------+ | |
| +------------------+ | | +------------------+ |
+-------------------------+ +-------------------------+
Smart Network Element Smart Network Element
¶
In this network scenario, the MCP client is deployed in the network controller while the MCP server is deployed in either the 3rd party management system or external data source. The MCP client communicates with the MCP server using the MCP protocol and invokes specific tools and gets access to specific data in the 3rd party management system or external data source.¶
+------------------------+ +------------+ | | | 3rd party | | Network Controller | | Management | | +-------+ | | System | | | MCP +-+--+ |+----------+| | | Client+-+--+--->MCP Server|| | +-------+ | | |+----------+| | | | +------------+ | | | | | | +------------+ | | | | | | | | |Data Source | | | | |+----------+| | | |--->MCP Server|| | | |+----------+| | | | | +------------------------+ +------------+¶
In this network scenario, the MCP client is deployed in the network controller while the MCP server is deployed standalone to manage all the network elements. For legacy networks, native MCP implementation on individual Network Elements can be redundant or resource-constrained. Instead, pre-existing network automation scripts (e.g., Python scripts powered by pyATS or Netmiko) can be directly refactored as MCP tools.¶
In this scenario, the standalone MCP server or Network Controller hosts these scripts and exposes them to the MCP client via standardized tool descriptors. When an AI agent requests a device operation, the MCP server invokes the corresponding Python script via local shell execution or tool pools. This approach achieves direct device control and backward compatibility without modifying the legacy device control plane.¶
+----------------------+
| |
| Network Controller |
| |
| +------------+ |
| | | |
+--------+----| MCP Client +----+----------+
| | | | | |
| | +-----+------+ | |
| +----------+-----------+ |
| | |
| +--------------V---------------+ |
| | MCP Server | |
| +--------^-------------^-------+ |
V | | V
+-------------+ | | +-------------+
| | | | | |
| Data Source |--------+- |--------+ Tools |
| | | |
+------+------+ +------+------+
| |
(Telemetry/gNMI) (CLI/FastCLI/Shell)
| |
+------V---------------------------------------------V------+
| Automation & Adaption Scripts (e.g., Python, pyATS) |
+------------------------------+----------------------------+
|
V
+--------------+
| Legacy Device|
+--------------+
Network Element
¶
In this network scenario, the MCP client is deployed in the network gateway device while the MCP server is deployed in each network device. The MCP client communicates with the MCP server using the MCP protocol. The LLM is a pre-trained model and deployed in the same Network gateway as the MCP client.¶
Network devices usually have limited resources (CPU, memory, etc.). Deploying MCP Server may occupy a large amount of resources, affecting the normal operation of the device.¶
+------------------------+
| Network Controller/ |
| Network Gateway |
| |
| Natural |
| +------Language------+ |
| | MCP | | LLM | |
| | Client|-----| | |
| +-+-----+ +------+ |
| |MCP |
+---+--------------------+
+----------------+
+--------+---+ +------+------+
| +-----++ | | +---+--+ |
| | MCP || | | | MCP | |
| |Server| | | |Server| |
| +------+ | | +------+ |
+------------+ +-------------+
Network Element Network Element
¶
Objective: Allow AI models (such as Claude) to understand natural language commands and trigger operations.¶
Workflow:¶
Intent Recognition: The LLM first analyzes the user's natural language query to identify：¶
Network Entity Object Extraction：The LLM or a apecialized sub-module extracts network-specificsemantic entities (e.g.,Device Names, Interface IDs, Protocal Instances, VRF contexts) from the input. These extracted entities are mapped onto a network semantic graph or topology data model to ensure that the paramenters paased to the MCP tool correspond to valid, existing operational assets.¶
Tool Discovery and Toolchain Generation: The LLM accesses tool descriptions provided by MCP servers, and matches the identified intent with available tools.¶
Parameter Extraction and Mapping: The LLM maps natural language references to structured parameter names and extracts relevant information from the user query.¶
Structured Invocation Generation: The LLM generates properly formatted tool calls following MCP's protocol.¶
Benefits:¶
Bridge natural language to tool invocation requests in a fixed format, then return this request to the client, enabling the client to properly parse the request.¶
Objective: Realize the closed loop of "voice/text commands → automatic execution" leveraging local memory and tools.¶
A general workflow is as follows:¶
User Input Submission: An operator submits a natural language request to the MCP client, which forwards the query to the LLM.¶
LLM Intent Processing: The LLM parses the input and identifies the operational intent. The MCP client then quiries the MCP server via HTTP GET to retrieve the registered tools and their associated schemas.¶
Tool Discovery and Context Retrieval:¶
If the LLM requires network knowledge or baseline history to process the intent, it invokes the respective tool. Taking RAG tool as an example, this tool may generate a query embedding and perform a top-K similarity search against the vector database.¶
The retrieved document or memory records are returned to the LLM as a structured prompt context.¶
Tool Decision and Execution:¶
The LLM evaluates the context, determines the execution sequence, and returns a structured post request to the MCP client. The MCP client executes the toolchain via HTTP POST.¶
For configuration and diagnostic tasks, the MCP server invokes respective tool to parse parameters and capture stdout/stderr outputs.¶
Result Aggregation & Feedback: The MCP client collates the JSON outputs (e.g., success or error messages) and forwards them to the LLM for summarization. The execution logs and final decisions are persisted as Markdown files in the long-term memory module on a certain retention cycle.¶
Benefits:¶
MCP can be seen as AI protocol and used to invoke AI integrated capabilities. MCP is not in the position to replace the network management and YANG data model. Instead, it can be integrated together, e.g.,¶
This document has no IANA actions.¶
The MCP protocol needs to consider scenarios where either the client or server encounters issues, such as crashes. If one or both parties go offline during communication, the entire process may remain stuck waiting for messages, potentially leading to an infinite loop. Furthermore, certain tool operations may be interrupted, and some irreversible network management operations could be affected.¶
Due to network latency, some operations might not return in time, yet from the user's perspective, these operations may appear either unexecuted or failed. If the user then initiates another tool request to the server, problems may occur.¶
For complex network management workflows, while LLM's tool invocation process may generally function correctly, issues can arise in the details. Users must verify each LLM operation to prevent unintended hazardous actions.¶
Capability metadata associated with MCP-exposed network management tools may assist MCP clients and AI agents in evaluating operational risk, rollback capabilities, and approval requirements prior to tool invocation. Orchestration systems may use such metadata to enforce authorization, approval, and policy constraints as part of the execution workflow. This distinction can help reduce unsafe or unintended operations in AI-assisted network management environments by allowing clients and agents to consume metadata for planning, while enforcement points apply policy controls before execution.¶
+-----------------------------------------------------------------+ | Smart Network Element | | | | +-------------------------------------------------------------+ | | | Dev Env: Offline Generate fault location workflow code | | | | | | | | +----------+ +---------+ | | | | | Expert | +----------+ |fault | | | | | |experience| | Protocol | +-----+ |Locating | | | | | |accumulate+-> Knowledge+--> LLM +--->Workflow | | | | | | protocol | | RAG | +-----+ | Code | | | | | | fault | +----------+ +----+----+ | | | | +----------+ | | | | +------------------------------------------------+------------+ | | | | | | | | | | | +------------------------------------------------+------------+ | | |OPS Env:Online Natural Language Interaction------V-------+ | | | | +----------+Troubleshooting| | | | | | | Package Build| | | | | | +---------------+ | | | |+--------+ +----V---+ +-------------+ | | | || User | +-------+ |Intent | | Execute | | | | || Nature | | Device| |Parse | |Workflow | | | | ||Language+--> SLM +--->Fault +----> Script | | | | || Prompt | | ONNX | |Pattern | |Locating root| | | | |+--------+ +-------+ |Match | | Cause | | | | | +--------+ +-------------+ | | | | | | | +-------------------------------------------------------------+ | +-----------------------------------------------------------------+¶
Step 1. When ISIS neighbour establishment fails, the network maintenance engineer queries the fault cause via natural language in the CLI interface.¶
Step 2. A small model deployed on the device's CPU understands the user's intent and matches the fault pattern.¶
Step 3. Troubleshooting scripts are invoked to locate the root cause of the fault.¶
Step 4. The query is repeated until service operations get back to normal.¶
In this example, the network element implements the MCP Server and exposes all CLI interfaces and documentation as tools to the MCP Client. The Network controller implements the MCP client and interact with MCP server in the Network element.¶
The MCP server provides the following registered tool descriptor information:¶
Tools description: It describes the name, use, and parameters of tools.¶
Tools implementation: MCP implementation describes how the tools are invoked.¶
See Tool descriptor information example as follows:¶
# Tool Descriptor
[
{
"name": "batch_configure_devices",
"description": "Batch Configure Network Devices",
"parameters": {
"type": "object",
"properties": {
"device_ips": {
"type": "array",
"items": {"type": "string"},
"description": "Device IP List"
},
"commands": {
"type": "array",
"items": {"type": "string"},
"description": "CLI Sequence"
},
"credential_id": {
"type": "string",
"description": "Credential ID"
}
},
"required": ["device_ips", "commands"]
}
},
{
"name": "check_device_status",
"description": "Check the Status of Network Devices",
"parameters": {
"type": "object",
"properties": {
"device_ip": {"type": "string"},
"metrics": {
"type": "array",
"items": {"enum": ["cpu", "memory", "interface"]}
}
},
"required": ["device_ip"]
}
}
]
# Tool Implementation
from netmiko import ConnectHandler
from mcp_server import McpServer
app = FastAPI()
server = McpServer(app)
#Connection Pool Management
devices = {
"192.168.1.1": {
"device_type": "VendorA-XYZ",
"credential": "admin:XYZ@password"
},
"192.168.1.2": {
"device_type": "VendorB-ABC",
"credential": "admin:ABC@password"
},
...
}
@server.tool("batch_configure_devices")
async def batch_config(device_ips: list,commands: list,credential_id: str):
results = {}
for ip in device_ips:
conn = ConnectHandler(
ip = ip,
username = devices[ip]["credential"].split(':')[0],
password = devices[ip]["credential"].split(':')[1],
device_type = devices[ip]["device_type"]
)
output = conn.send_config_set(commands)
results[ip] = output
return {"success": True, "details": results}
@server.tool("check_device_status")
async def check_status(device_ip: str, metrics: list):
status = {}
if "cpu" in metrics:
status["cpu"] = get_cpu_usage (device_ip)
if "memory" in metrics:
status["memory"] = get_memory_usage(device_ip)
return status
¶
Suppose a user submits a request (via the client) such as "Configure OSPF Area 0 with process ID 100 for all core switches in the Beijing data center," the MCP client retrieves the necessary tooling descriptor information from the MCP server and forwards it along with the request to the LLM. The LLM determines the appropriate tools and responds in JSON format as follows:¶
{
"method": "batch_configure_devices",
"params": {
"device_ips":["192.168.10.1",....,"192.168.10.10"],
"command": [
"router ospf 100",
"network 192.168.0.0 0.0.255.255 area 0"
]
}
}
}
¶
The MCP server responds to the call instruction, converts it into the below CLIs of different vendors, and then the devices execute the CLIs. The results are returned to the MCP client in JSON as below and are forwarded to the LLM. The LLM parses the response, generates a natural-language summary, and sends it back to the client for final presentation to the user.¶
# Convert to CLI commands of different vendors
"commands": [
"system-view",
"ospf {{process_id}}",
"area {{area_id}}",
"network {{network_address}} {{wildcard_mask}}"
]
"commands": [
"configure terminal",
"router ospf {{process_id}}",
"network {{network_address}} {{wildcard_mask}} area {{area_id}}",
"end",
"write memory"
]
#Feedbacks received by the MCP client of different vendors
{
"status": "success",
"message": "OSPF configuration applied successfully on device
192.168.10.1",
"commands_executed": [
"system-view",
"ospf 100",
"area 0.0.0.0",
"network 192.168.10.0 0.0.0.255"
]
}
{
"status": "success",
"message": "OSPF configuration applied successfully on device
192.168.10.1",
"commands_executed": [
"configure terminal",
"router ospf 100",
"network 192.168.10.0 0.0.0.255 area 0",
"end",
"write memory"
]
}
# Natural language summary of success or failure:
{
"192.168.10.1": "Configure Successfully, take 2.3 seconds",
"192.168.10.2": "Error: no response from the device",
}
¶