| |
|
| |
| | RESTCONF Client and Server Models |
| |
|
This document presents two YANG modules, one module to configure a RESTCONF client and the other module to configure a RESTCONF server. Both modules support the TLS transport protocol with both standard RESTCONF and RESTCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * IIII --> the assigned RFC value for this draft * JJJJ --> the assigned RFC value for draft-ietf-netconf-udp-client- server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2025-04-02 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log |
| | NETCONF Client and Server Models |
| |
|
This document presents two YANG modules, one module to configure a NETCONF client and the other module to configure a NETCONF server. Both modules support both the SSH and TLS transport protocols, and support both standard NETCONF and NETCONF Call Home connections. Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * BBBB --> the assigned RFC value for draft-ietf-netconf-trust- anchors * CCCC --> the assigned RFC value for draft-ietf-netconf-keystore * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * EEEE --> the assigned RFC value for draft-ietf-netconf-ssh-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for draft-ietf-netconf-http- client-server * HHHH --> the assigned RFC value for this draft Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2025-02-12 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log |
| | An HTTPS-based Transport for YANG Notifications |
| |
|
This document defines a protocol for sending asynchronous event notifications similar to notifications defined in RFC 5277, but over HTTPS. YANG modules for configuring publishers are also defined. Examples are provided illustrating how to configure various publishers. This document requires that the publisher is a "server" (e.g., a NETCONF or RESTCONF server), but does not assume that the receiver is a server. |
| | YANG Groupings for HTTP Clients and HTTP Servers |
| |
|
This document presents two YANG modules: the first defines a minimal grouping for configuring an HTTP client, and the second defines a minimal grouping for configuring an HTTP server. It is intended that these groupings will be used to help define the configuration for simple HTTP-based protocols (not for complete web servers or browsers). Editorial Note (To be removed by RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements (note: not all may be present): * AAAA --> the assigned RFC value for draft-ietf-netconf-crypto- types * DDDD --> the assigned RFC value for draft-ietf-netconf-tcp-client- server * FFFF --> the assigned RFC value for draft-ietf-netconf-tls-client- server * GGGG --> the assigned RFC value for this draft * JJJJ --> the assigned RFC value for draft-ietf-netconf-udp-client- server Artwork in this document contains placeholder values for the date of publication of this draft. Please apply the following replacement: * 2025-02-12 --> the publication date of this draft The "Relation to other RFCs" section Section 1.1 contains the text "one or more YANG modules" and, later, "modules". This text is sourced from a file in a context where it is unknown how many modules a draft defines. The text is not wrong as is, but it may be improved by stating more directly how many modules are defined. The "Relation to other RFCs" section Section 1.1 contains a self- reference to this draft, along with a corresponding reference in the Appendix. Please replace the self-reference in this section with "This RFC" (or similar) and remove the self-reference in the "Normative/Informative References" section, whichever it is in. Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792. However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify what looks ugly and ask the authors to make the adjustment. The following Appendix section is to be removed prior to publication: * Appendix A. Change Log |
| | Subscription to Distributed Notifications |
| |
|
This document describes extensions to the YANG notifications subscription to allow metrics being published directly from processors on line cards to target receivers, while subscription is still maintained at the route processor in a distributed forwarding system. |
| | UDP-based Transport for Configured Subscriptions |
| |
| | draft-ietf-netconf-udp-notif-20.txt |
| | Date: |
03/03/2025 |
| | Authors: |
Guangying Zheng, Tianran Zhou, Thomas Graf, Pierre Francois, Alex Feng, Paolo Lucente |
| | Working Group: |
Network Configuration (netconf) |
|
This document describes a UDP-based transport for YANG notifications to collect data from network nodes. A shim header is defined to facilitate the data streaming directly from a publishing process on a network device to telemetry receivers. Such a design enable higher frequency updates and less performance overhead on publisher and receiver processes compared to already established notification mechanisms. A YANG data model is also defined for management of the described UDP-based transport. |
| | Adaptive Subscription to YANG Notification |
| |
|
This document defines a YANG data model and associated mechanism that enable adaptive subscription to YANG notifications. The periodic update interval for the stream can be set adaptively. Applying adaptive subscription allows publishers to adjust the subscription period dynamically based on pre-defined threshold for finer-grained network telemetry data sent to receivers. |
| | List Pagination for YANG-driven Protocols |
| |
|
In some circumstances, instances of YANG modeled "list" and "leaf- list" nodes may contain numerous entries. Retrieval of all the entries can lead to inefficiencies in the server, the client, and the network in between. This document defines a model for list pagination that can be implemented by YANG-driven management protocols such as NETCONF and RESTCONF. The model supports paging over optionally filtered and/or sorted entries. The solution additionally enables servers to constrain query expressions on some "config false" lists or leaf- lists. |
| | NETCONF Extensions to Support List Pagination |
| |
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to NETCONF [RFC6241]. This document updates [RFC6241], to augment the and "rpc" statements, and [RFC8526], to augment the "rpc" statement, to define input parameters necessary for list pagination. |
| | RESTCONF Extensions to Support List Pagination |
| |
|
This document defines a mapping of the list pagination mechanism defined in [I-D.ietf-netconf-list-pagination] to RESTCONF [RFC8040]. This document updates RFC 8040, to declare "list" and "leaf-list" as valid resource targets for the RESTCONF GET operation, to define GET query parameters necessary for list pagination, and to define a media-type for XML-based lists. |
| | Updates to Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication |
| |
|
RFC 7589 defines how to protect NETCONF messages with TLS 1.2. This document updates RFC 7589 to update support requirements for TLS 1.2 and add TLS 1.3 support requirements, including restrictions on the use of TLS 1.3's early data. |
| | Transaction ID Mechanism for NETCONF |
| |
|
NETCONF clients and servers often need to have a synchronized view of the server's configuration data stores. The volume of configuration data in a server may be very large, while data store changes typically are small when observed at typical client resynchronization intervals. Rereading the entire data store 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. |
| | Support of Versioning in YANG Notifications Subscription |
| |
|
This document extends the YANG notifications subscription mechanism to specify the YANG module semantic version at the subscription. Then, a new extension with the revision and the semantic version of the YANG push subscription state change notification is proposed. |
| | NETCONF Private Candidates |
| |
|
This document provides a mechanism to extend the Network Configuration Protocol (NETCONF) and RESTCONF protocol to support multiple clients making configuration changes simultaneously and ensuring that they commit only those changes that they defined. This document addresses two specific aspects: The interaction with a private candidate over the NETCONF and RESTCONF protocols and the methods to identify and resolve conflicts between clients. |
| | External Trace ID for Configuration Tracing |
| |
|
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. |
| | YANG Groupings for UDP Clients and UDP Servers |
| |
|
This document defines two YANG 1.1 modules with reusable groupings for managing UDP clients and UDP servers. |
| | NETCONF Extension to support Trace Context propagation |
| |
|
This document defines how to propagate trace context information across the Network Configuration Protocol (NETCONF), that enables distributed tracing scenarios. It is an adaption of the HTTP-based W3C specification. |
| | RESTCONF Extension to Support Trace Context Headers |
| |
|
This document defines an extension to the RESTCONF protocol in order to support Trace Context propagation as defined by the W3C. |
| | NETCONF over QUIC |
| |
| | draft-ietf-netconf-over-quic-02.txt |
| | Date: |
25/02/2025 |
| | Authors: |
Jinyou Dai, Shaohua Yu, Weiqiang Cheng, Marc Blanchet, Per Andersson |
| | Working Group: |
Network Configuration (netconf) |
|
This document specifies how to use QUIC as a secure transport for exchanging Network Configuration Protocol (NETCONF) messages. QUIC provides encryption properties similar to TLS, while eliminating TCP head-of-line blocking issues and also providing more loss detection and congestion control than UDP. NETCONF over QUIC has privacy properties similar to NETCONF over TLS. Editorial note (to be removed by the RFC Editor This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * BBBB --> the assigned RFC value for draft-ietf-netconf-netconf- client-server * CCCC --> the assigned RFC value for draft-ietf-netconf-quic- client-server |
| | Augmented-by Addition into the IETF-YANG-Library |
| |
|
This document augments the ietf-yang-library to provide the augmented-by list. It facilitates the process of obtaining all dependencies between YANG modules, by querying the network management server's YANG library. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/Zephyre777/draft-lincla-netconf-yang-library- augmentation. |
| | YANG Groupings for QUIC clients and QUIC servers |
| |
|
This document defines three YANG 1.1 modules to support the configuration of QUIC clients and QUIC servers. The modules include basic parameters for configuring QUIC based clients and servers. Editorial note (To be removed by the RFC Editor) This draft contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: * AAAA --> the assigned RFC value for this draft * CCCC --> the assigned RFC value for draft-ietf-netconf-udp-client- server |
| | NETCONF Transport Port Numbers |
| |
|
This document releases NETCONF-related port number IANA assignments that were made for inappropriate transport protocols or for Historic NETCONF-related protocols. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Network Configuration Working Group mailing list (netconf@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/netconf/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/netconf-port-numbers. |
| | Extensible YANG Model for YANG-Push Notifications |
| |
|
This document defines a new extensible notification structure, defined in YANG, for use in YANG-Push Notification messages enabling any YANG compatible encodings such as XML, JSON or CBOR. Additionally, it defines two essential extensions to this structure, the support of a hostname and a sequence number and the support of a timestamp characterizing the moment when the changed data was observed. |
| | YANG Notification Transport Capabilities |
| |
|
This document specifies a YANG module for YANG notifications transport capabilities which augments "ietf-system-capabilities" YANG module defined in [RFC9196]. The module provides transport, encoding, and encryption system capabilities for transport-specific notification. This YANG module can be used by the client to learn capability information from the server at runtime or at implementation time, by making use of the YANG instance data file format. |