Hi Chongfeng,
We believe we have addressed all of your feedback (there is still an
ongoing discussion around AI though).
We had two draft versions posted since July 7th
Can we please review our temp version at
https://github.com/IETF-OPSAWG-WG/draft-opsarea-rfc5706bis
Thanks and regards, Benoit (on behalf of the authors)
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 toopsawg-le...@ietf.org
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
