Hi Joe,
Thank you for considering some text there. Also, I'd like to correct my mistake in the name, it should be "Network Large Model", which has its definition at ITU-T M.3080Amd1 as below, "Network Large Model: An artificial intelligence algorithm system for telecom management, which has the large-scale parameters and complex computational structure." I agree with you currently AI tool doesn't warrant any changes people might do to a protocol， but for the new operation protocols to be designed in the future, ithere is possibility that they are specifically customized for AI tools. I will review the text and send my comments. Best regards Chongfeng From: Joe Clarke (jclarke) Date: 2025-08-07 21:56 To: Chongfeng Xie; opsawg Subject: Re: [OPSAWG]AI in operational considerations (Was: Re: Some comments on RFC5706-bis) We discussed this on our authors’ call today, and while we don’t think there are tooling considerations per se, the data hungriness or AI can lead to considerations in performance management and scalability. I’ll propose some text there and get your take on it. Joe From: Joe Clarke (jclarke) <[email protected]> Date: Thursday, August 7, 2025 at 08:50 To: Chongfeng Xie <[email protected]>, opsawg <[email protected]> Subject: Re: [OPSAWG]AI in operational considerations (Was: Re: Some comments on RFC5706-bis) Thanks, Chongfeng. I agree with the sentiment in this paragraph (though I’m not sure what the proper, “Big Network Models” is, in general I know of generic network-tuned models), but I don’t see what action this would have for document authors when it comes to management and operations-based tooling. First, I wouldn’t want to call out any specific tools, especially AI tools, in the document as they change rapidly. Second, any text should trigger thoughts in an author about what they would build into the protocol or call out for implementors or operations. I agree that AI can consume large amounts of data both of a protocol directly (e.g., take in route server, BGP-LS, etc. data) or management data about protocols (IPFIX, telemetry), but this in and of itself doesn’t warrant any changes I might do to a protocol (other than what is already part of the document about considering how protocols like IPFIX or YANG Push might be useful). Joe From: Chongfeng Xie <[email protected]> Date: Wednesday, August 6, 2025 at 02:34 To: Joe Clarke (jclarke) <[email protected]>, opsawg <[email protected]> Subject: Re: [OPSAWG]AI in operational considerations (Was: Re: Some comments on RFC5706-bis) 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 <[email protected]> Date: Sunday, July 6, 2025 at 20:51 To: opsawg <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
