Hi Chongfeng,


Hi Benoit,

After reviewing the latest version (v0.5) of the draft, I noticed that my feedback has been taken into account and that the new changes are fine.

Great.

Also, there is one nit in section 1,

    s/dociument/document

Now corrected at https://github.com/IETF-OPSAWG-WG/draft-opsarea-rfc5706bis

Regards, Benoit
Best regards
Chongfeng

    *From:* [email protected] <mailto:[email protected]>
    *Date:* 2025-08-28 22:04
    *To:* Chongfeng Xie <mailto:[email protected]>; opsawg
    <mailto:[email protected]>
    *Subject:* [OPSAWG]Re: Some comments on RFC5706-bis
    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 [email protected]
    To unsubscribe send an email [email protected]

_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to