Hi Joe,

I think the current text of "New Tools "does not fully capture the growing AI 
trend  in network operations, so I provide the following text for "AI Tools", 

"AI-based tools, such as Network Big Models, are now being integrated into 
network management. Trained on large-scale, high-quality professional data and 
knowledge, these tools support network analysis, automatic operation, fault 
management, and overall optimization, enabling operators to tackle increasingly 
complex tasks.  Specifically, by leveraging collection and control 
capabilities, AI-based tools can manage and control network device protocols."

Hope to hear comments on this from you and the WG.

Best regards
Chongfeng


 
From: Joe Clarke \(jclarke\)
Date: 2025-07-31 22:28
To: Chongfeng Xie; opsawg
Subject: [OPSAWG]AI in operational considerations (Was: Re: Some comments on 
RFC5706-bis)
Hey, Chongfeng.  Thanks for your review!
 
The authors just discussed it.  Some of your comments are well-understood and 
will be incorporated into the draft.  I want to take a moment to talk about 
your AI suggestion.
 
I agree that AI is everywhere and already being used heavily in network 
management.  Things like Model Context Protocol and tool-calling models can 
make excellent use of network telemetry and operational data.  However, they 
are using the same APIs and hooks that already exist (e.g., SNMP, YANG-based 
protocols, CLI, streaming protocols, etc.).  We don’t see what one would 
consider specific to AI other than making sure the technical specification 
(i.e., the protocol or protocol extension) outlines metrics that should be 
exposed and what protocols might expose such metrics.
 
The tooling section as it is, is generic enough that how its backend analytics 
are implemented (heuristics, AI, statistical models) it wouldn’t matter so long 
as the tool could be made to understand the specific aspects of the new 
protocol.
 
That said, if you have specific text recommendations, we’d like to discuss them.
 
Joe (on behalf of the authors)
 
From: Chongfeng Xie <chongfeng....@foxmail.com>
Date: Sunday, July 6, 2025 at 20:51
To: opsawg <opsawg@ietf.org>
Subject: [OPSAWG]Some comments on RFC5706-bis
 
 
Hi Benoit, authors,
 
I have given a review to RFC5706-bis, which provides guidlines on writing 
"Considering Operations and Management" in future IETF drafts, I think this 
effort will make the IETF output to be more aligned with the operational 
requirements of operators, therefore it is very valuable. I also have the 
following comments for your consideration,
 
 
1) In Section 2.1, there is   "Operation activities that are undertaken to keep 
the network."
 
It seems that this sentence is incomplete, can it be changed to the following 
or something like that?
  "Operation activities that are undertaken to keep the network run normally."
 
2) Section 2.2 mentions Radius as a management technology, Based on RFC2865  
"Radius is a protocol for carrying authentication,  authorization, and 
configuration information between a Network Access”
 
However, I think the  term of "management" in this document is mainly about how 
to manage “New Protocols or Protocol Extensions,I don't think Radius belongs to 
this categoy,  so it is not related to the subject of this document. 
 
3) In section 3.2,  there is "There are no new operations or manageability 
requirements introduced by this document,"
 
Since RFC5706-bis mainly deals the mangement and operation issus of new 
standard, instead of new draft , so it is possible to be changed to the 
following?
"There are no specific operations or manageability requirements introduced by 
this protocol (or protocol extension),"
 
4) In Section 5, there is  
"The management model should take into account factors such as: What type of 
management entities will be involved (agents, network management systems)?"
 
I propose to add "network Controller" to the list, so the setence is change to 
"The management model should take into account factors such as: What type of 
management entities will be involved (agents, network controller, network 
management systems)?"
 
5) Section 5.3 is about fault management, 
 
With the increasing number of protocols in the network, operators are 
particularly concerned about the stability and impact of new protocols 
(including extensions of existing protocols). They are concerned about whether 
issuing protocol configuration instructions will have an impact on the normal 
operation of the network. The impact of different protocols on network 
stability and security varies during deployment. Improper configuration of one 
instruction may lead to widespread network failures and even serious losses. 
Therefore, it is recommended to analyze and explain the possible impact of new 
protocols or extensions, if there is a fault, What is its impact level 
(single-device level, AS level, operator level, neighour operators level,  or 
the whole Internet)?  and provide necessary reminders in the documentation on 
how to avoid such wrong configurations.
 
6) Section 5.6.1 is about the performance management of protocol. I think 
performance is heavily decided by the resource provided, in particular, 
hardware resource provided, for instance, for the same protocol, hardware based 
implementation usually has better performance than that of software-based, so I 
think the term of "performance" works for equipment, instead of protocol. Since 
this draft is about how to write“ Considering Operations and Management in IETF 
specifications”, from the perspective of protocol, do we need to keep the 
section of perfromance? 
 
7) Section 6 is about"Operational and Management Tooling Considerations", I 
suggest adding AI-based system here,such as AI agent.
 
This is because the adoption of AI technology in network management and 
operation has become an important trend. Considering that an RFC will serve for 
many years in the future, we should mention it in this section.
 
8) The purpose of RFC5706-bis is to instruct authors on how to write 
"Considering Operations and Management" in their IETF standard. Currently, its 
length is a bit long, and in order to facilitate its use, I suggest that the 
final version can reduce its length and mainly list instructions on how to 
write "considerations". Analytical or supportive content can be moved to the 
auxiliary section.
 
 
 
Thank you!
 
 
Best regards
Chongfeng
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org

Reply via email to