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