%% You should probably cite draft-quilbeuf-netconf-configuration-tracing instead of this I-D.
@techreport{quilbeuf-opsawg-configuration-tracing-00,
    number =    {draft-quilbeuf-opsawg-configuration-tracing-00},
    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/00/},
    author =    {Jean Quilbeuf and Benoît Claise and Thomas Graf and Diego Lopez and Sun Qiong},
    title =     {{External Transaction ID for Configuration Tracing}},
    pagetotal = 15,
    year =      2022,
    month =     oct,
    day =       20,
    abstract =  {Network equipments are often configured by a variety of network management systems (NMS), protocols, and people. If a network issue arises because of a wrong configuration modification, it's important to quickly identify the specific service request and obtain the reason for pushing that modification. Another potential network issue can stem from concurrent NMS's with overlapping intent, each having their own tasks to perform: in such a case, it's important to map the respective modifications to its originating NMS. This document specifies a mechanism to automatically map the configuration modifications to their source, up to a specific NMS service request, in the context of NETCONF. Such a mechanism is required for autonomous networks, to trace the reason of a particular configuration change that lead to an anomaly detection or a broken SLA. This mechanism facilitates the troubleshooting, the post mortem analysis, and in the end the closed loop automation required for self-healing networks. The specifications contain a new YANG module mapping a local configuration change to the corresponding northbound transaction, up to the controller or even the orchestrator.},
}