%% You should probably cite draft-quilbeuf-netconf-configuration-tracing instead of this I-D.
@techreport{quilbeuf-opsawg-configuration-tracing-01,
    number =    {draft-quilbeuf-opsawg-configuration-tracing-01},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-quilbeuf-opsawg-configuration-tracing/01/},
    author =    {Jean Quilbeuf and Benoît Claise and Thomas Graf and Diego Lopez and Sun Qiong},
    title =     {{External Transaction ID for Configuration Tracing}},
    pagetotal = 16,
    year =      2023,
    month =     mar,
    day =       13,
    abstract =  {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 change transaction, up to the controller or even the orchestrator.},
}