Early Review of draft-ietf-netconf-configuration-tracing-05
review-ietf-netconf-configuration-tracing-05-yangdoctors-early-ma-2025-04-18-00

Hi, authors, WG,

I am the assigned YANG Doctor to review this draft, and here are my review
comments.

This document defines a short YANG module to maintain the mapping between each
configuration change with the corresponding originating source and trace
information leveraging the other work in NETCONF WG.

Moderate comments:
• I think this work should be applicable to both NETCONF and RESTCONF
protocols. But I found some parts in the draft are quite specific to NETCONF, I
suggest the authors to check it throughout the draft and make sure both
protocols are considered. For example,
        • Abstract says "This document specifies a NETCONF mechanism to
        automatically map the configuration modifications to their source, up
        to a specific NMS change request." • introduction (e.g., the last
        paragraph) • Sec.4.1, 4.2, and 4.3.

• The draft defines a XML attribute to pass client-id in sec.4.3, I expect the
definition of the client-id attribute to be more clearly explained in a
dedicated section. E.g., which operations are legal with this attribute? what
is the type of this attribute, string? how is this attribute passed for
RESTCONF? and how to pass this for JSON encoding? What if the server doesn’t
understand this attribute, throw an error vs. safe ignore?

Minor comments:
• Sec.3
   "Here are the use cases for the proposed YANG module; they are extensions of
   the "Provisioning root cause analysis" use case presented in Section 1.3.1
   of [I-D.ietf-netconf-trace-ctx-extension]."
I think it is in section 1.4.1 now.

• Sec.4.4
        • "The YANG module defined below enables tracing a configuration change
        in a Network Equipment back to its origin, for instance a service
        request in an orchestrator." Maybe add a reference to the section
        number rather than stating "the YANG module defined below", I think
        that would be clearer.

        • I think it is worth mentioning in sec.4.4 the instance data of the
        yang module needs to be maintained in all levels, i.e., the NE,
        controller and orchestrator.

        • I am unsure if you should define Anomaly Detection System, or add
        some reference to the work in NMOP.

• Sec.5
        • Keeping the definition of trace-parent elements(e.g., version,
        trace-id, parent-id, trace-flags) consistent with W3C trace context is
        good, please also add a formal reference statement to trace-context
        spec so that people can understand why these leaves have their specific
        types and lengths. • For parent-id leaf, values with all zeroes
        forbidden, so I guess a must statement same with trace-id is also
        needed?

Nits:
• Sec.4.3
OLD: For 'tx-2' and 'tx-3', the client is the id of the Controller.
NEW: For 'tx-2' and 'tx-3', the client id is the id of the Controller.

• Sec.5
        • The revision in the YANG module is 2022-10-20, but the yang file name
        is ietf-external-transaction-id@2021-11-03.yang. • Please keep the
        author information in the YANG module consistent with the draft.

Best Regards,
Qiufang