<?xml version="1.0" encoding="UTF-8"?>
<reference anchor="I-D.ietf-netconf-configuration-tracing" target="https://datatracker.ietf.org/doc/html/draft-ietf-netconf-configuration-tracing-06">
   <front>
      <title>External Trace ID for Configuration Tracing</title>
      <author initials="J." surname="Quilbeuf" fullname="Jean Quilbeuf">
         <organization>Huawei</organization>
      </author>
      <author initials="B." surname="Claise" fullname="Benoît Claise">
         <organization>Everything OPS</organization>
      </author>
      <author initials="T." surname="Graf" fullname="Thomas Graf">
         <organization>Swisscom</organization>
      </author>
      <author initials="D." surname="Lopez" fullname="Diego Lopez">
         <organization>Telefonica I+D</organization>
      </author>
      <author initials="S." surname="Qiong" fullname="Sun Qiong">
         <organization>China Telecom</organization>
      </author>
      <date month="November" day="3" year="2025" />
      <abstract>
	 <t>   Network equipment are often configured by a variety of network
   management systems (NMS), protocols, and teams.  If a network issue
   arises (e.g., because of a wrong configuration change), it is
   important to quickly identify the root cause and obtain the reason
   for pushing that modification.  Another potential network issue can
   stem from concurrent NMSes with overlapping intents, each having
   their own tasks to perform.  In such a case, it is important to map
   the respective modifications to its originating NMS.

   This document specifies a NETCONF mechanism to automatically map the
   configuration modifications to their source, up to a specific NMS
   change request.  Such a mechanism is required, in particular, for
   autonomous networks to trace the source of a particular configuration
   change that led to an anomaly detection.  This mechanism facilitates
   the troubleshooting, the post-mortem analysis, and in the end the
   closed loop automation required for self-healing networks.  The
   specification also includes a YANG module that is meant to map a
   local configuration change to the corresponding trace id, up to the
   controller or even the orchestrator.

	 </t>
      </abstract>
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-netconf-configuration-tracing-06" />
   
</reference>
