]> Ionio Systems

per.ietf@ionio.se

OPS Area NETCONF Working Group This document defines five 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 as well as initial modules for the IANA registries "QUIC Versions" and "QUIC Transport Parameters". 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

Introduction This documents defines two YANG 1.1 modules to support the configuration of QUIC clients and QUIC servers (QUIC is defined in ), either as standalone or in conjunction with configuration of other protocol layers.

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. The following terms are defined in and are not redefined here: client, data model, data tree, feature, extension, module, leaf, leaf-list, and server.

The "ietf-quic-common" Module This section defines a YANG 1.1 module called "ietf-quic-common". This YANG module has normative references to , , , , , and .

Data model overview This section presents an overview of of the "ietf-quic-common" module in terms of features and groupings.

Groupings The "ietf-quic-common" module defines the following "grouping" statement:

• transport-parameters

This grouping is presented in the following subsection.

The "quic-common" Grouping The following tree diagram illustrates the "quic-common" grouping: Comments:

• This grouping contains common transport parameters for QUIC connections.

YANG Module <CODE BEGINS> file "ietf-quic-common@2026-02-12.yang" WG Web: https://datatracker.ietf.org/wg/netconf Author: Per Andersson "; description "This module defines a reusable grouping that is common for QUIC clients and QUIC servers. This grouping statement is used by both 'ietf-quic-client' and 'ietf-quic-server' modules. Copyright (c) 2026 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 AAAA (https://www.rfc-editor.org/info/rfcAAAA); 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-02-12 { description "Initial version"; reference "RFC AAAA: YANG Groupings for QUIC Clients and QUIC Servers"; } // Groupings grouping version { description "A reusable grouping for QUIC Versions."; reference "RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport RFC 9369: QUIC Version 2"; leaf-list version { type iana-quic-versions:version; description "The QUIC versions supported."; } } grouping transport-parameters { description "A reusable grouping for QUIC Transport Parameters."; reference "RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport RFC 9221: An Unreliable Datagram Extension to QUIC RFC 9287: Greasing the QUIC Bit RFC 9312: Manageability of the QUIC Transport Protocol RFC 9368: Compatible Version Negotiation for QUIC"; leaf leaf-list { type iana-quic-transport:transport-parameter; description "A leaf list containing the QUIC transport parameters."; } } } ]]> <CODE ENDS>

The "ietf-quic-client" Module This section defines a YANG 1.1 module called "ietf-quic-client".

Data model overview This section presents an overview of of the "ietf-quic-client" module in terms of features and groupings.

Features The module itself does not define any features. However, in order to require TLS 1.3 the following "if-feature" is defined "tlscmn:tls13 not tlscmn:tls12". For QUIC TLS requirements see . For further details about available features see the "ietf-tls-client" and "ietf-udp-client" modules. defined in and respectively.

Groupings The "ietf-quic-client" module defines the following "grouping" statement:

• quic-client

This grouping is presented in the following subsection.

The "quic-client" Grouping The following tree diagram illustrates the "quic-client" grouping: Comments:

• This grouping uses the "tls-client-grouping" grouping discussed in . Note that QUIC requires TLS 1.3 (or later), thus the "if-feature" invariant "tlscmn:tls13 and not tlscmn:tls12" is defined for this grouping.
• This grouping uses the "udp-client-grouping" grouping discussed in .

YANG Module This YANG module has normative references to and . <CODE BEGINS> file "ietf-quic-client@2026-02-12.yang" WG Web: https://datatracker.ietf.org/wg/netconf Author: Per Andersson "; description "This module defines reusable groupings for QUIC clients that can be used as a basis for specific QUIC client instances. Copyright (c) 2026 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 AAAA (https://www.rfc-editor.org/info/rfcAAAA); 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-02-12 { description "Initial version"; reference "RFC AAAA: YANG Groupings for QUIC Clients and QUIC Servers"; } // Groupings grouping quic-client { description "Grouping to configure a QUIC client."; reference "RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport"; uses tlsc:tls-client-grouping { if-feature "tlscmn:tls13 and not tlscmn:tls12"; description "QUIC requires that TLS 1.3 (or later) is used."; reference "RFC 9001: Using TLS to Secure QUIC"; } uses udpc:udp-client; uses quiccmn:transport-parameters; } } ]]> <CODE ENDS>

The "ietf-quic-server" Module This section defines a YANG 1.1 module called "ietf-quic-server".

Data model overview This section presents an overview of of the "ietf-quic-server" module in terms of features and groupings.

Features The module itself does not define any features. However, in order to require TLS 1.3 the following "if-feature" is defined "tlscmn:tls13 not tlscmn:tls12". For QUIC TLS requirements see . For further details about available features see the "ietf-tls-server" and "ietf-udp-server" modules, defined in and respectively.

Groupings The "ietf-quic-server" module defines the following "grouping" statement:

• quic-server

This grouping is presented in the following subsection.

The "quic-server" Grouping The following tree diagram illustrates the "quic-server" grouping: Comments:

• This grouping uses the "tls-server-grouping" grouping discussed in . Note that QUIC requires TLS 1.3 (or later), thus the "if-feature" invariant "tlscmn:tls13 and not tlscmn:tls12" is defined for this grouping.
• This grouping uses the "udp-server-grouping" grouping discussed in .

YANG Module This YANG module has normative references to and . <CODE BEGINS> file "ietf-quic-server@2026-02-12.yang" WG Web: https://datatracker.ietf.org/wg/netconf Author: Per Andersson "; description "This module defines reusable groupings for QUIC servers that can be used as a basis for specific QUIC server instances. Copyright (c) 2026 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 AAAA (https://www.rfc-editor.org/info/rfcAAAA); 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-02-12 { description "Initial version"; reference "RFC AAAA: YANG Groupings for QUIC Clients and QUIC Servers"; } // Features // FIXME feature quic-call-home // Groupings grouping quic-server { description "Grouping to configure a QUIC server."; reference "RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport"; uses tlss:tls-server-grouping { if-feature "tlscmn:tls13 and not tlscmn:tls12"; description "QUIC requires that TLS 1.3 (or later) is used."; reference "RFC 9001: Using TLS to Secure QUIC"; } uses udps:udp-server; uses quiccmn:transport-parameters; } } ]]> <CODE ENDS>

Security Considerations This section follows the template defined in Section 3.7.1 of . The YANG modules specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . 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 modules presented in this draft does not contain any protocol accessible nodes, and thus the security considerations for such are not provided here. Furthermore, the modules defines groupings, these considerations are primarily for the designers of other modules that use these groupings. Security considerations for the groupings used in the modules are discussed in and , refer to these documents for further details. Since the modules does not define any RPCs or actions or notifications, and thus the security considerations for such are not provided here.

IANA Considerations

The "IETF XML" Registry This document registers five URIs in the "ns" subregistry of the IETF XML Registry maintained at . Following the format in , the following registration is requested:

The "YANG Module Names" Registry This document registers five YANG modules in the YANG Module Names registry maintained at . Following the format defined in , the below registration is requested:

Considerations for IANA Maintained Modules The initial YANG modules are created with the iana-yang tool from <https://github.com/llhotka/iana-yang>.

The "iana-quic-versions" Module IANA is requested to maintain a YANG module called "iana-quic-versions" that shadows the "QUIC Versions" registry . Ths registry defines a YANG enumeration for each QUIC version. An initial version of this module can be found in .

• Note that this module was created on July 6th, 2025, and that additional entries may have been added before this document's publication. If this is the case, IANA may publish an updated module containing the new entries, or publish the initial module with a "revision" containing the additional QUIC versions.

The "iana-quic-transport" Module IANA is requested to maintain a YANG module called "iana-quic-transport" that shadows the "QUIC Transport Parameters" registry . Ths registry defines a YANG enumeration for each QUIC transport parameter. An initial version of this module can be found in . Since the QUIC Transport Parameters registry may have provisionally registered names change value when they are made permanent, make the following considerations.

• If an existing name exists in the module, update the value in the description field.
• Since normative changes to enum descriptions are non-backwards-compatible, the YANG Semver version need to update the MAJOR version number. Note that this follows normal YANG Semver versioning rules. .

• Note that this module was created on July 6th, 2025, and that additional entries may have been added before this document's publication. If this is the case, IANA may publish an updated module containing the new entries, or publish the initial module with a "revision" containing the additional QUIC transport parameters.

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. 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. 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 a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). 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 memo provides guidelines for authors and reviewers of specifications containing 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 6087. 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 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 describes how Transport Layer Security (TLS) is used to secure QUIC. This document discusses manageability of the QUIC transport protocol and focuses on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It is intended as a "user's manual" for the wire image to provide guidance for network operators and equipment vendors who rely on the use of transport-aware network functions. This document defines an extension to the QUIC transport protocol to add support for sending and receiving unreliable datagrams over a QUIC connection. This document describes a method for negotiating the ability to send an arbitrary value for the second-most significant bit in QUIC packets. QUIC does not provide a complete version negotiation mechanism but instead only provides a way for the server to indicate that the version the client chose is unacceptable. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an extra round trip. This document updates RFC 8999. This document specifies QUIC version 2, which is identical to QUIC version 1 except for some trivial details. Its purpose is to combat various ossification vectors and exercise the version negotiation framework. It also serves as a template for the minimum changes in any future version of QUIC. Note that "version 2" is an informal name for this proposal that indicates it is the second version of QUIC to be published as a Standards Track document. The protocol specified here uses a version number other than 2 in the wire image, in order to minimize ossification risks. This document presents four YANG 1.1 modules -- three IETF modules and one supporting IANA module. The three IETF modules are "ietf-tls-common", "ietf-tls-client", and "ietf-tls-server". The "ietf-tls-client" and "ietf-tls-server" modules are the primary productions of this work, supporting the configuration and monitoring of TLS clients and servers. The IANA module is "iana-tls-cipher-suite-algs". This module defines YANG enumerations that provide support for an IANA-maintained algorithm registry. Informative References YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.

YANG Modules for IANA The initial YANG modules are created with the iana-yang tool from <https://github.com/llhotka/iana-yang>.

Initial Module for the "QUIC Versions" Registry This YANG module has normative references to and . <CODE BEGINS> file "iana-quic-versions@2025-09-23.yang" "; description "This YANG module translates IANA registry 'QUIC Versions' to YANG derived types. Copyright (c) 2025 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 was generated from the corresponding IANA registry using an XSLT stylesheet from the 'iana-yang' project (https://github.com/llhotka/iana-yang)."; reference "QUIC (https://www.iana.org/assignments/quic/)"; revision 2025-09-23 { description "Current revision as of the revision date specified in the XML representation of the registry page."; reference "https://www.iana.org/assignments/quic/quic.xml"; } /* Typedefs */ typedef quic-version { type enumeration { enum 0x00000000 { description "(permanent) Reserved for Version Negotiation"; reference "RFC 9000"; } enum 0x00000001 { description "(permanent)"; reference "RFC 9000"; } enum 0x51303433 { description "(provisional) Google QUIC Q043"; } enum 0x51303436 { description "(provisional) Google QUIC Q046"; } enum 0x51303530 { description "(provisional) Google QUIC Q050"; } enum 0x6b3343cf { description "(permanent)"; reference "RFC 9369"; } enum 0x709a50c4 { description "(provisional) QUIC v2 draft codepoint"; reference "RFC 9369"; } } description "This enumeration type defines QUIC protocol versions."; reference "RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport"; } typedef version { type quic-version; description "This type allows reference to a QUIC version using the assigned value."; } } ]]> <CODE ENDS>

Initial Module for the "QUIC Transport Parameters" Registry This YANG module has normative references to , , , , and , <CODE BEGINS> file "iana-quic-transport@2025-09-23.yang" "; description "This YANG module translates IANA registry 'QUIC Transport Parameters' to YANG derived types. Copyright (c) 2025 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 was generated from the corresponding IANA registry using an XSLT stylesheet from the 'iana-yang' project (https://github.com/llhotka/iana-yang)."; reference "QUIC (https://www.iana.org/assignments/quic/)"; revision 2025-09-23 { description "Current revision as of the revision date specified in the XML representation of the registry page."; reference "https://www.iana.org/assignments/quic/quic.xml"; } /* Typedefs */ typedef quic-transport-parameter { type enumeration { enum original_destination_connection_id { description "0x00 (permanent)"; reference "RFC 9000"; } enum max_idle_timeout { description "0x01 (permanent)"; reference "RFC 9000"; } enum stateless_reset_token { description "0x02 (permanent)"; reference "RFC 9000"; } enum max_udp_payload_size { description "0x03 (permanent)"; reference "RFC 9000"; } enum initial_max_data { description "0x04 (permanent)"; reference "RFC 9000"; } enum initial_max_stream_data_bidi_local { description "0x05 (permanent)"; reference "RFC 9000"; } enum initial_max_stream_data_bidi_remote { description "0x06 (permanent)"; reference "RFC 9000"; } enum initial_max_stream_data_uni { description "0x07 (permanent)"; reference "RFC 9000"; } enum initial_max_streams_bidi { description "0x08 (permanent)"; reference "RFC 9000"; } enum initial_max_streams_uni { description "0x09 (permanent)"; reference "RFC 9000"; } enum ack_delay_exponent { description "0x0a (permanent)"; reference "RFC 9000"; } enum max_ack_delay { description "0x0b (permanent)"; reference "RFC 9000"; } enum disable_active_migration { description "0x0c (permanent)"; reference "RFC 9000"; } enum preferred_address { description "0x0d (permanent)"; reference "RFC 9000"; } enum active_connection_id_limit { description "0x0e (permanent)"; reference "RFC 9000"; } enum initial_source_connection_id { description "0x0f (permanent)"; reference "RFC 9000"; } enum retry_source_connection_id { description "0x10 (permanent)"; reference "RFC 9000"; } enum version_information { description "0x11 (permanent)"; reference "RFC 9368"; } enum max_datagram_frame_size { description "0x20 (permanent)"; reference "RFC 9221"; } enum discard { description "0x173e (provisional) Receiver silently discards."; reference "https://github.com/quicwg/base-drafts/wiki /Quantum-Readiness-test"; } enum google_handshake_message { description "0x26ab (provisional) Used to carry Google internal handshake message"; } enum grease_quic_bit { description "0x2ab2 (permanent)"; reference "RFC 9287"; } enum initial_rtt { description "0x3127 (provisional) Initial RTT in microseconds"; } enum google_connection_options { description "0x3128 (provisional) Google connection options for experimentation"; } enum user_agent { status deprecated; description "0x3129 (provisional) User agent string (deprecated)"; } enum google_version { description "0x4752 (provisional) Google QUIC version downgrade prevention"; } enum version_information_draft { status deprecated; description "0xff73db (provisional) Deprecated; use version_information instead"; reference "draft-ietf-quic-version-negotiation-13"; } enum google_debug_1 { description "0x219bbcd0 (provisional)"; } enum min_ack_delay { description "0xff04de1b (provisional)"; reference "draft-ietf-quic-ack-frequency-07"; } enum enable_multipath { description "0x0f739bbc1b666d05 (provisional)"; reference "draft-ietf-quic-multipath-05"; } enum enable_multipath-06 { description "0x0f739bbc1b666d06 (provisional)"; reference "draft-ietf-quic-multipath-06"; } enum initial_max_path_id { description "0x0f739bbc1b666d0d (provisional)"; reference "draft-ietf-quic-multipath-15"; } enum bdp_frame { description "0x4143414213370002 (provisional)"; reference "draft-misell-quic-bdp-token-02"; } } description "This enumeration type defines QUIC transport parameters."; reference "RFC 9000: QUIC: A UDP-Based Multiplexed and Secure Transport"; } typedef transport-parameter { type quic-transport-parameter; description "This type allows reference to a QUIC transport parameters using the assigned value."; } } ]]> <CODE ENDS>