Hi Chongfeng,
Thanks for your review.
You provided feedback on the revision 2 and we posted a new revion just
after your post.
See inline
On 7/7/2025 2:44 AM, Chongfeng Xie wrote:
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."
Yes, we will correct.
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.
We want however to provide a couple of quick pointers to existing
management protocols and data models.
See also https://github.com/IETF-OPSAWG-WG/draft-opsarea-rfc5706bis/issues/7
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)*,"
Let us discuss this one with the authors.
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)?"
That makes sense to me
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.
Let us discuss this one with the authors.
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？
Let us discuss this one with the authors.
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.
That makes at first glance. Now, it's a tough one. I fear the "oh, AI
will fix this operations of XXX" type of reactions. And it's an
instruction for an AI agent, it seems a little bit early to me
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.
Point well taken. I mentioned during the draft presentation.
See https://github.com/IETF-OPSAWG-WG/draft-opsarea-rfc5706bis/issues/96
Regards, Benoit
Thank you!
Best regards
Chongfeng
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
