]> Cisco Systems

Avenue des Uttins 5 Rolle 1180 Switzerland rogaglia@cisco.com

Cisco Systems

crenners@cisco.com

Deutsche Telekom AG

kll@dev.terastrm.net

All For Eco

jan.lindblad+ietf@for.eco

Operations and Management Network Configuration telemetry distributed systems opentelemetry This document defines how to propagate trace context information across the Network Configuration Protocol (NETCONF), enabling distributed tracing scenarios. It is an adaptation of the HTTP-based W3C specification and defines three YANG modules. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Network Configuration Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Network automation and management systems commonly consist of multiple subsystems, and together with the network devices they manage, they effectively form a distributed system. Distributed tracing is a methodology implemented by tracing tools to follow, analyze, and debug operations such as configuration transactions across multiple distributed systems. An operation is uniquely identified by a trace-id, and through a trace context carries metadata about the operation. Propagating this "trace context" between systems enables a coherent view of the entire operation as carried out by all involved systems. The W3C has defined two HTTP headers for context propagation that are useful in use case scenarios for distributed systems such as those described in . This document defines an extension to the NETCONF protocol to add the same concepts and enable trace context propagation over NETCONF. It is worth noting that the trace context is not meant to be related to the data carried with a given operation, including configurations, service identifiers, or state information. A trace context also differs from in several ways: the trace operation may involve any operation (including, for example, validate, lock, unlock, etc.). Additionally, a trace context scope may include the full application stack (orchestrator, controller, devices, etc.) rather than a single NETCONF server, which is the scope for the transaction-id. The trace context is also complementary to because a given trace-id can be associated with different transaction-ids as part of the information exported to the collector. The following enhancement of the reference SDN Architecture from shows the impact of distributed traces for a network operator.

A Sample SDN Architecture from RFC8309 augmented to include the export of metrics, events, logs and traces from the different components to a common collector. | | .------------------. | | . : . | | . : . | Collector | +------------+ +------------+ +------------+ | (Metrics, | | | | | | | | Events, | | Controller | | Controller | | Controller | --> | Logs, | | | | | | | | Traces) | +------------+ +------------+ +------------+ | | : . . : | | : . . : | | : . . : | | +---------+ +---------+ +---------+ +---------+ | | | Network | | Network | | Network | | Network | | | | Element | | Element | | Element | | Element | -> | | +---------+ +---------+ +---------+ +---------+ +-----------+ ]]>

The network automation, management and control architectures are distributed in nature. In order to "manage the managers", operators would like to use the same techniques as any other distributed systems in their IT environment. Solutions for analysing Metrics, Events, Logs and Traces (M.E.L.T) are key for the successful monitoring and troubleshooting of such applications. Initiatives such as the OpenTelemetry enable rich ecosystems of tools that NETCONF-based applications would want to participate in. With the implementation of this trace context propagation extension to NETCONF, backend systems behind the M.E.L.T collector will be able to correlate information from different systems but related to a common context. This document does not cover the somewhat related functionality specified in . Mapping of the Baggage functionality into YANG may be specified in a future document.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Additionally, this document uses the following abbreviations:

OTLP:

OpenTelemetry protocol as defined by

M.E.L.T.:

Metrics, Events, Logs and Traces

gNMI:

gRPC Network Management Interface, as defined by

The XML prefixes used in this document are mapped as follows:

• xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0",
• xmlns:w3ctc="urn:ietf:params:xml:ns:netconf:w3ctc:1.0" and
• xmlns:ietf-trace-context= "urn:ietf:params:xml:ns:yang:ietf-trace-context"

Implementation example 1: OpenTelemetry The following example illustrates the value of trace context propagation in the NETCONF protocol. In the OTLP Sample Architecture below, we show a deployment based on the RFC8309 sample architecture above, with a single controller and two network elements. In this example, the NETCONF protocol is running between the Orchestrator and the Controller. NETCONF is also used between the Controller and the Network Elements. Assume an edit-config operation between the orchestrator and the controller that results (either synchronously or asynchronously) in corresponding edit-config operations from the Controller toward the two network elements. All trace operations are related and will create M.E.L.T. data.

An implementation example where the NETCONF protocol is used between the Orchestrator and the Controller and also between the Controller and the Network Elements. Every component exports M.E.L.T information to the collector using the OTLP protocol. | | .------------------+ | | . NETCONF | | . edit-config (trace-id "1", parent-id "A") | Collector | +------------+ | (Metrics, | | | | Events, | | Controller | ------------------------------------> | Logs, | | | OTLP protocol | Traces) | +------------+ | | : . NETCONF | | : . edit-config (trace-id "1", parent-id "B") | | : . | | +---------+ +---------+ | | | Network | | Network | OTLP protocol | | | Element | | Element | --------------------------> | | +---------+ +---------+ +-----------+ ]]>

Each of the components in this example (Orchestrator, Controller and Network Elements) is exporting M.E.L.T information to the collector using the OpenTelemetry Protocol (OTLP). For every edit-config operation, the trace context is included. In particular, the same trace-id "1" (simplified encoding for documentation) is included in all related NETCONF messages, which enables the collector and any backend application to correlate all M.E.L.T messages related to this transaction in this distributed stack. Another interesting attribute is the parent-id. We can see in this example that the parent-id between the orchestrator and the controller ("A") is different from the one between the controller and the network elements ("B"). This attribute will help the collector and the backend applications to build a connectivity graph to understand how M.E.L.T information exported from one component relates to the information exported from a different component. With this additional metadata exchanged between the components and exposed to the M.E.L.T collector, there are important improvements to the monitoring and troubleshooting operations for the full application stack.

Implementation example 2: YANG Datastore OpenTelemetry implements the "push" model for data streaming where information is sent to the back-end as soon as produced and is not required to be stored in the system. In certain cases, a "pull" model may be envisioned, for example for performing forensic analysis while not all OTLP traces are available in the back-end systems. An implementation of a "pull" mechanism for M.E.L.T. information in general and for traces in particular, could consist of storing traces in a YANG datastore (particularly the operational datastore.) Implementations should consider the use of circular buffers to avoid resource exhaustion. External systems could access traces (and particularly past traces) via NETCONF, RESTCONF, gNMI or other polling mechanisms. Finally, storing traces in a YANG datastore enables the use of YANG-Push or gNMI Telemetry as additional "push" mechanisms. This document does not specify the YANG module in which traces could be stored inside the different components. That said, storing the context information described in this document as part of the recorded traces would allow back-end systems to correlate the information from different components as in the OpenTelemetry implementation.

An implementation example where the NETCONF protocol is used between the Orchestrator and the Controller and also between the Controller and the Network Elements. M.E.L.T. information is stored in local YANG Datastores and accessed by the collector using "pull" mechanisms using the NETCONF (NC), RESTCONF (RC) or gNMI protocols. A "push" strategy is also possible via YANG-Push or gNMI. | | .------------------+ pull or push | | . NETCONF | | . edit-config (trace-id "1", parent-id "A") | Collector | +----------------+ | (Metrics, | | | NC/RC/gNMI or YP | Events, | | Controller | <-------------------------------> | Logs, | | YANG Datastore| pull or push | Traces) | +----------------+ | | : . NETCONF | | : . edit-config (trace-id "1", parent-id "B") | | : . | | +---------+ +---------+ | | | Network | | Network | NC/RC/gNMI or YP | | | Element | | Element | <-------------------------> | | | YANG DS | | YANG DS | pull or push | | +---------+ +---------+ +-----------+ ]]>

Use Cases

Provisioning root cause analysis When a provisioning activity fails, errors are typically propagated northbound, however this information may be difficult to troubleshoot and typically, operators are required to navigate logs across all the different components. With the support for trace context propagation as described in this document for NETCONF, the collector will be able to search every trace, event, metric, or log in connection to that trace-id and facilitate the performance of a root cause analysis due to a network changes. The trace information could also be included as an optional resource with the different NETCONF transaction ids described in .

System performance profiling When operating a distributed system such as the one shown in , operators are expected to benchmark Key Performance Indicators (KPIs) for the most common tasks. For example, what is the typical delay when provisioning a VPN service across different controllers and devices. Thanks to Application Performance Management (APM) systems, from these KPIs, an operator can detect a normal and abnormal behaviour of the distributed system. Also, an operator can better plan any upgrades or enhancements in the platform. With the support for context propagation as described in this document for NETCONF, much richer system-wide KPIs can be defined and used for troubleshooting as the metrics and traces propagated by the different components share a common context. Troubleshooting for abnormal behaviours can also be troubleshot from the system view down to the individual element.

Billing and auditing In certain circumstances, we could envision tracing information used as additional inputs to billing systems. In particular, trace context information could be used to validate that a certain northbound order was carried out in southbound systems.

NETCONF Extension When performing NETCONF operations by sending NETCONF RPCs, a NETCONF client MAY include trace context information in the form of XML attributes. The defines two HTTP headers; traceparent and tracestate for this purpose. NETCONF clients that are taking advantage of this feature MUST add one w3ctc:traceparent attribute and MAY add one w3ctc:tracestate attribute to the nc:rpc tag. A NETCONF server that receives a trace context attribute in the form of a w3ctc:traceparent attribute SHOULD apply the mutation rules described in . A NETCONF server MAY add one w3ctc:traceparent attribute in the nc:rpc-reply response to the nc:rpc tag above. NETCONF servers MAY also add one w3ctc:traceparent attribute in notification and update message envelopes: notif:notification, yp:push-update and yp:push-change-update. For example, a NETCONF client might send: ]]> In all cases above where a client or server adds a w3ctc:traceparent attribute to a tag, that client or server MAY also add one w3ctc:tracestate attribute to the same tag. The proper encoding and interpretation of the contents of the w3ctc:traceparent attribute is described in section 3.2 except 3.2.1. The proper encoding and interpretation of the contents in the w3ctc:tracestate attribute is described in section 3.3 except 3.3.1 and 3.3.1.1. A NETCONF XML tag can only have zero or one w3ctc:tracestate attributes, so its content MUST always be encoded as a single string. The tracestate field value is a list of list-members separated by commas (,). A list-member is a key/value pair separated by an equals sign (=). All whitespace surrounding list members is ignored. There is no limit to the number of list members in a list. For example, a NETCONF client might send: ]]> As in all XML documents, the order between the attributes in an XML tag has no significance. Clients and servers MUST be prepared to handle the attributes no matter in which order they appear. The tracestate value MAY contain double quotes, commas (,), or equals (=) signs in its payload. If so, they MUST be encoded according to XML rules to avoid injection attacks, for example: ]]>

Error handling When interacting with these extensions, the NETCONF server follow the specifications of section 2.3 in . A detailed processing model example is also provided in the document. Based on this processing model, it is NOT RECOMMENDED to reject an RPC because of the trace context attribute values. If the server still decides to reject the RPC because of the trace context attribute values, ietf-trace-context.yang SHOULD be included in the YANG library and the server MUST return a NETCONF rpc-error with the following values: Additionally, the error-info tag MUST contain a trace-context-error-info structure with relevant details about the error. This structure is defined in the module ietf-trace-context.yang. Example of a badly formatted trace context extension: ]]> This might give the following error response: protocol operation-failed error Context traceparent attribute incorrectly formatted w3ctc:traceparent Bad Format ietf-trace-context:bad-format ]]>

Trace Context extension versioning This extension refers to the trace context capability. The W3C traceparent and tracestate headers include the notion of versions. It would be desirable for a NETCONF client to be able to discover the one or multiple versions of these headers supported by a server. To achieve this goal, and to avoid having to define a new NETCONF extension for each headers version, we define a pair of YANG modules (ietf-trace-ctx-traceparent-1.0.yang and ietf-trace-ctx-tracestate-1.0.yang) that MUST be included in the YANG library per of the NETCONF server supporting the NETCONF Trace Context extension. These YANG module capabilities will refer to the headers' supported versions. Future updates of this document could include additional YANG modules for new headers' versions.

YANG Modules This document defines three YANG modules:

YANG module for ietf-trace-context structure This YANG module has normative references to [RFC8791]. WG List: Authors: Roque Gagliano Christian Rennerskog Jan Lindblad Kristian Larsson "; description "When propagating tracing information across applications, client and servers need to share some specific contextual information. This extension aligns the NETCONF and RESTCONF protocols to the W3C trace-context document: https://www.w3.org/TR/2021/REC-trace-context-1-20211123 This document has a normative reference to RFC 8791. Copyright (c) 2024 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. "; revision 2026-10-25 { description "Initial revision"; reference "RFC XXXX: NETCONF Extension to support Trace Context propagation"; } identity meta-error { description "Base identity for trace context attribute errors."; } identity missing { base meta-error; description "Indicates an attribute or header that is required (in the current situation) is missing."; } identity bad-format { base meta-error; description "Indicates an attribute or header value where the value is incorrectly formatted."; } identity processing-error { base meta-error; description "Indicates that the server encountered a processing error while processing the attribute or header value."; } typedef meta-error-type { type identityref { base meta-error; } description "Error type"; } sx:structure trace-context-error-info { description "This error is returned by a NETCONF or RESTCONF server when a client sends a NETCONF RPC with additional attributes or RESTCONF RPC with additional headers for trace context processing, and there is an error related to them. The server has aborted the RPC."; leaf meta-name { type string; mandatory true; description "The name of the problematic or missing meta information. In NETCONF, the qualified XML attribute name. In RESTCONF, the HTTP header name. If a client sent a NETCONF RPC with the attribute w3ctc:traceparent='incorrect-format' this leaf would have the value 'w3ctc:traceparent'"; } leaf meta-value { type string; mandatory true; description "The value of the problematic meta information received by the server. If a client sent a NETCONF RPC with the attribute w3ctc:traceparent='incorrect-format' this leaf would have the value 'incorrect-format'."; } leaf error-type { type meta-error-type; mandatory true; description "Indicates the type of meta information problem detected by the server. If a client sent an RPC annotated with the attribute w3ctc:traceparent='incorrect-format' this leaf might have the value 'ietf-trace-context:bad-format'."; } } } ]]>

YANG module for traceparent header version 1.0 WG List: Authors: Roque Gagliano Christian Rennerskog Jan Lindblad Kristian Larsson "; description "This module documents the support for trace context traceparent version 1.0 in alignment with W3C versions: https://www.w3.org/TR/2021/REC-trace-context-1-20211123 This module is used for capability advertisement only, without any YANG data nodes. Copyright (c) 2024 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. "; revision 2026-10-25 { description "Initial revision"; reference "RFC XXXX: NETCONF Extension to support Trace Context propagation"; } } ]]>

YANG module for tracestate header version 1.0 WG List: Authors: Roque Gagliano Christian Rennerskog Jan Lindblad Kristian Larsson "; description "This module documents the support for trace context tracestate version 1.0 in alignment with W3C versions: https://www.w3.org/TR/2021/REC-trace-context-1-20211123 This module is used for capability advertisement only, without any YANG data nodes. Copyright (c) 2024 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. "; revision 2026-10-25 { description "Initial revision"; reference "RFC XXXX: NETCONF Extension to support Trace Context propagation"; } } ]]>

Security Considerations This section is modeled after the template described in Section 3.7 of . The ietf-trace-context, ietf-trace-ctx-tracestate-1.0 and ietf-trace-ctx-traceparent-1.0 YANG modules define data models that are designed to be accessed via YANG-based management protocols, such as NETCONF and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. The YANG modules specified in this document are used to flag capabilities support and to define an error information structure. As such, these YANG modules do not contain any configuration data, state data or RPC definitions, which makes their security implications very limited. The additional attributes specified in this document (but not in YANG modules, since YANG cannot be used to specify attributes) are worth mentioning, however. The traceparent and tracestate attributes make it easier to track the flow of requests and their downstream effect on other systems. This is indeed the whole point with these attributes. This knowledge could also be of use to bad actors that are working to build a map of the managed network. The meta-name and meta-value attributes in the ietf-trace-context.yang should not echo any information received from an erroneous request or the system, in order to avoid bad actors receiving additional contextual information. When bad values are encountered, further processing of them should stop immediately.

IANA Considerations This document registers the following capability identifier URN in the 'Network Configuration Protocol (NETCONF) Capability URNs' registry: This document registers one XML namespace URN in the 'IETF XML registry', following the format defined in (https://www.rfc-editor.org/rfc/rfc3688.html). This document registers three module names in the 'YANG Module Names' registry, defined in RFC 6020: and and

Acknowledgments The authors would like to acknowledge the valuable feedback from Per Andersson. Many thanks to Raul Rivas Felix, Alexander Stoklasa, Luca Relandini and Erwin Vrolijk for their help with the demos regarding integrations. The help and support from Jean Quilbeuf and Benoit Claise has also been invaluable to this work.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document describes a YANG library that provides information about the YANG modules, datastores, and datastore schemas used by a network management server. Simple caching mechanisms are provided to allow clients to minimize retrieval of this information. This version of the YANG library supports the Network Management Datastore Architecture (NMDA) by listing all datastores supported by a network management server and the schema that is used by each of these datastores. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules. Informative References All For Eco NETCONF clients and servers often need to have a synchronized view of the server's configuration datastores. The volume of configuration data in a server may be very large, while datastore changes typically are small when observed at typical client resynchronization intervals. Rereading the entire datastore and analyzing the response for changes is inefficient for synchronization. This document specifies a NETCONF extension that allows clients and servers to keep synchronized with a much smaller data exchange and without any need for servers to store information about the clients. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. The IETF has produced many modules in the YANG modeling language. The majority of these modules are used to construct data models to model devices or monolithic functions. A small number of YANG modules have been defined to model services (for example, the Layer 3 Virtual Private Network Service Model (L3SM) produced by the L3SM working group and documented in RFC 8049). This document describes service models as used within the IETF and also shows where a service model might fit into a software-defined networking architecture. Note that service models do not make any assumption of how a service is actually engineered and delivered for a customer; details of how network protocols and devices are engineered to deliver a service are captured in other modules that are not exposed through the interface between the customer and the provider.

Appendix A: Example of yang-library for trace context This document includes three YANG modules, two of which are used only for publishing the traceparent and tracestate header versions. This is an example of a YANG library response for the modules in this document.       common                   ietf-netconf-otlp-context           2023-07-01           urn:ietf:params:xml:ns:yang:otlp-context                   ietf-netconf-otlp-context-traceparent-version-1.0       2024-11-07       urn:ietf:params:xml:ns:yang:traceparent:1.0               ietf-netconf-otlp-context-tracestate-version-1.0       2024-11-07       urn:ietf:params:xml:ns:yang:tracestate:1.0       ]]>

Changes (to be deleted by RFC Editor)

From version 09 to version 10

• Aligned YANG module filenames with revision dates and updated both to 2026-10-25
• Fixed typo in Section 3.1 (additonal -> additional)

From version 08 to version 09

• updated dates on YANG
• typos
• Grammar cleanups

From version 07 to version 08

• Added comments from YANG DOCTOR review, includding adding mandatory leafs, adding a tree file, adding an appendix with the yang-library example
• Added Christian Rennerskog as co-author

From version 06 to version 07

• All Shepperd comments.
• Corrected missing period in YANG modules to avoid pyang warning.
• Clarifies that all whitespaces are ignored.
• Enhanced tracestate encoding guidance to explicitly mention commas (,) and equals (=) signs must be encoded per XML rules to avoid injection attacks.
• Enhanced Security Considerations to clarify that meta-name and meta-value should not echo erroneous requests and that further processing should stop immediately when bad values are encountered.
• Added clarification that Clients and servers MUST be prepared to handle special characters in tracestate values.

From version 05 to version 06

• We introduced a bug in the YANG model in version 03 as container was not needed per RFC 8791.
• Serveral edits based on OpsDir comments

From version 04 to version 05

• More WGLC and sheepard comments

From version 03 to version 04

• WGLC data change.

From version 02 to 03

• Changed document Abbreviation
• trace-context-error-info is a container in example

From version 01 to 02

• Enhanced Terminology and moved it up in the document.
• Changed namespaces and module names to map WGLC comments and IETF requirements

From version 00 to 01

• Added Security considerations
• Added Acknowledgements
• Added several Normative references
• Updated link to latest document on github
• Firmed up error handling and YANG-library to MUST-requirements

From version 03 to draft-ietf-netconf-trace-ctx-extension-00

• Adopted by NETCONF WG
• Moved repository to NETCONF WG
• Changed build system to use martinthomson's excellent framework
• Ran make fix-lint to remove white space at EOL etc.
• Added this change note. No other content changes.

From version 02 to 03

• Changed IANA section to IESG per IANA email
• Created sx:structure and improved error example
• Added ietf-netconf-otlp-context.yang for the sx:structure
• Created a dedicated section for the YANG modules

From version 01 to 02

• Added Error Handling intial section
• Added how to manage versioning by defining YANG modules for each traceparent and trastate versions as defined by W3C.
• Added 'YANG Module Names' to IANA Considerations

From version 00 to 01

• Added new section: Implementation example 2: YANG Datastore
• Added new use case: Billing and auditing
• Added in introduction and in "Provisioning root cause analysis" the idea that the different transaction-ids defined in could be added as part of the tracing information to be exported to the collectors, showing how the two documents are complementary.

XML Attributes vs RPCs input augmentations discussion (to be deleted by RFC Editor) There are arguments that can be raised regarding using XML Attribute or to augment NETCONF RPCs. We studied Pros/Cons of each option and decided to propose XML attributes: XML Attributes Pro:

• Literal alignment with W3C specification
• Same encoding for RESTCONF and NETCONF enabling code reuse
• One specification for all current and future RPCss

XML Attributes Cons:

• No YANG modeling, multiple values represented as a single string
• Dependency on W3C for any extension or changes in the future as encoding will be dictated by string encoding

RPCs Input Augmentations Pro:

• YANG model of every leaf
• Re-use of YANG toolkits
• Simple updates by augmentations on existing YANG module
• Possibility to express deviations in case of partial support

RPCs Input Augmentations Cons:

• Need to augment every RPC, including future RPCs would need to consider these augmentations, which is harder to maintain
• There is no literal alignment with W3C standard. However, as mentioned before most of the time there will be modifications to the content
• Would need updated RFP for each change at W3C, which will make adoption of new features slower