rfc9984xml2.original.xml   rfc9984.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc>
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="2"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc compact="yes"?> tf-netconf-udp-client-server-10" number="9984" updates="" obsoletes="" ipr="trus
<?rfc subcompact="no"?> t200902" submissionType="IETF" consensus="true" tocInclude="true" tocDepth="2" s
<rfc category="std" docName="draft-ietf-netconf-udp-client-server-10" ymRefs="true" sortRefs="true" version="3" xml:lang="en">
ipr="trust200902" submissionType="IETF" consensus="true"
xmlns:xi="http://www.w3.org/2001/XInclude">
<front> <front>
<!--[rfced] We note that most of the recently published RFCs
containing YANG modules format their titles as "A YANG Data Model
for...", for example:
RFC 9094 - A YANG Data Model for Wavelength Switched Optical Networks (WSONs
)
RFC 9093 - A YANG Data Model for Layer 0 Types
RFC 9067 - A YANG Data Model for Routing Policy
Please consider whether the title of this document should be updated.
Current:
YANG Groupings for UDP Clients and UDP Servers
Please also consider if the repetition of UDP is necessary:
Perhaps:
YANG Groupings for UDP Clients and Servers
(Note: the title appears in more places throughout the document.)
-->
<title abbrev="Groupings for UDP Clients and Servers">YANG Groupings for UDP <title abbrev="Groupings for UDP Clients and Servers">YANG Groupings for UDP
Clients and UDP Servers</title> Clients and UDP Servers</title>
<seriesInfo name="RFC" value="9984"/>
<author fullname="Alex Huang Feng" initials="A." surname="Huang-Feng"> <author fullname="Alex Huang Feng" initials="A." surname="Huang-Feng">
<organization>INSA-Lyon</organization> <organization>INSA-Lyon</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Lyon</city> <city>Lyon</city>
<region/>
<code/>
<country>France</country> <country>France</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>alex.huang-feng@insa-lyon.fr</email> <email>alex.huang-feng@insa-lyon.fr</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Pierre Francois" initials="P." surname="Francois"> <author fullname="Pierre Francois" initials="P." surname="Francois">
<organization>INSA-Lyon</organization> <organization>INSA-Lyon</organization>
<address> <address>
<postal> <postal>
<street/>
<city>Lyon</city> <city>Lyon</city>
<region/>
<code/>
<country>France</country> <country>France</country>
</postal> </postal>
<phone/>
<facsimile/>
<email>pierre.francois@insa-lyon.fr</email> <email>pierre.francois@insa-lyon.fr</email>
<uri/>
</address> </address>
</author> </author>
<author fullname="Kent Watsen" initials="K." surname="Watsen"> <author fullname="Kent Watsen" initials="K." surname="Watsen">
<organization>Watsen Networks</organization> <organization>Watsen Networks</organization>
<address> <address>
<email>kent+ietf@watsen.net</email> <email>kent+ietf@watsen.net</email>
</address> </address>
</author> </author>
<date month="May" year="2026"/>
<date day="16" month="December" year="2025"/> <area>OPS</area>
<workgroup>netconf</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<keyword>example</keyword>
<!--[rfced] We note that this document uses "defines" where other
documents in cluster C463 use "presents". Please let us know if
you'd like to update. Note that similar text appears more than
once in the document.
Original:
This document defines two YANG 1.1 modules with reusable
groupings for managing UDP clients and UDP servers.
Perhaps:
This document presents two YANG 1.1 modules with reusable
groupings for managing UDP clients and UDP servers.
-->
<!--[rfced] We note that RFC 9643 (that you mentioned in the document
intake form) and the other documents in cluster C463 all have a
section titled "Relation to Other RFCs". Please review and let
us know if any updates to this document are necessary. -->
<abstract> <abstract>
<t>This document defines two YANG 1.1 modules with reusable <t>This document defines two YANG 1.1 modules with reusable
groupings for managing UDP clients and UDP servers.</t> groupings for managing UDP clients and UDP servers.</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>Notes to the RFC editor</name>
<t>Please replace "RFC XXXX" with the assigned RFC number prior to publica
tion.
Note that there are also several occurrences of "RFC XXXX" in the YANG mod
ules.
</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction">
<name>Introduction</name>
<t>This document defines two YANG 1.1 <xref target="RFC7950"/> modules wit h reusable groupings <t>This document defines two YANG 1.1 <xref target="RFC7950"/> modules wit h reusable groupings
for managing UDP clients and UDP servers <xref target="RFC768"/>. for managing UDP clients and UDP servers <xref target="RFC768"/>.
These modules may be used directly (e.g., define These modules may be used directly (e.g., define
a specific UDP client or UDP server) or in conjunction with the configurat ion defined a specific UDP client or UDP server) or in conjunction with the configurat ion defined
for higher level protocols that depend on UDP.</t> for higher-level protocols that depend on UDP.</t>
<section>
<section title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP 14 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section>
<section title="Adherence to the NMDA"> <name>Adherence to the NMDA</name>
<t>This document is compliant with the Network Management Datastore <t>This document is compliant with the Network Management Datastore
Architecture (NMDA) <xref target="RFC8342"/>. It does not define Architecture (NMDA) <xref target="RFC8342"/>. It does not define
any protocol accessible nodes that are "config false".</t> any protocol-accessible nodes that are "config false".</t>
</section> </section>
<section>
<section title="Conventions"> <name>Conventions</name>
<t>Various examples in this document use the XML <xref target="W3C.REC-x ml-20081126"/> <t>Various examples in this document use the XML <xref target="W3C.REC-x ml-20081126"/>
encoding. Other encodings, such as JSON <xref target="RFC8259"/>, could alternatively be used.</t> encoding. Other encodings, such as JSON <xref target="RFC8259"/>, could alternatively be used.</t>
</section> </section>
</section> </section>
<section anchor="udp-client">
<section anchor="udp-client" title='The "ietf-udp-client" Module'> <name>The "ietf-udp-client" Module</name>
<t>This section defines a YANG 1.1 module called "ietf-udp-client". <t>This section defines a YANG 1.1 module called "ietf-udp-client".
This YANG module defines the "udp-client" This YANG module defines the "udp-client"
grouping for providing UDP clients with remote server information.</t> grouping for providing UDP clients with remote server information.</t>
<t><xref target="udp-client-overview"/> provides the overview of the <t><xref target="udp-client-overview"/> provides the overview of the
YANG module. An example of usage is illustrated YANG module. An example of usage is illustrated
in <xref target="example-client"/>, while <xref target="udp-client-ym"/> d efines the in <xref target="example-client"/>. <xref target="udp-client-ym"/> defines the
YANG module itself.</t> YANG module itself.</t>
<section anchor="udp-client-overview">
<section anchor="udp-client-overview" title='Data Model Overview'> <name>Data Model Overview</name>
<t>This section provides an overview of the features and the grouping de fined in the <t>This section provides an overview of the features and the grouping de fined in the
"ietf-udp-client" YANG module. "ietf-udp-client" YANG module.
</t> </t>
<section title="Features"> <section>
<name>Features</name>
<!--[rfced] Please review the use of "Features" (plural) in the
feature statement in Section 2.1.1. Elsewhere in the document we
see Feature (singular).
For example, in the module:
feature local-binding {
-->
<t>The "ietf-udp-client" module defines the following "feature" statem ent:</t> <t>The "ietf-udp-client" module defines the following "feature" statem ent:</t>
<sourcecode type="yangtree"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
Features: Features:
+-- local-binding +-- local-binding]]></sourcecode>
]]></sourcecode>
<t>The diagram above uses syntax that is similar to but not defined in
<xref target="RFC8340"/>.</t>
-- <span class="insert">local-binding]]&gt;&lt;/sourcecode&gt;</span>
<!--[rfced] Please review our update to the following text to ensure
we've maintained your intended meaning:
Original:
The diagram above uses syntax that is similar to but not defined in
[RFC8340].
Current:
The diagram above uses syntax that is similar to the syntax used in
[RFC8340]; but the syntax from the diagram is not defined in
[RFC8340].
-->
<t>The diagram above uses syntax that is similar to the syntax used in
<xref target="RFC8340"/>; but the syntax from the diagram is not defined in
<xref target="RFC8340"/>.</t>
<t>This feature indicates that the client supports <t>This feature indicates that the client supports
configuring local bindings (i.e., the local address and local port n umber) for UDP clients.</t> configuring local bindings (i.e., the local address and local port n umber) for UDP clients.</t>
</section> </section>
<section anchor="udp-client-grouping" title='The "udp-client" Grouping'> <section anchor="udp-client-grouping">
<name>The "udp-client" Grouping</name>
<t>The following tree diagram <xref target="RFC8340"/> illustrates the tree <t>The following tree diagram <xref target="RFC8340"/> illustrates the tree
structure of the "udp-client" grouping:</t> structure of the "udp-client" grouping:</t>
<sourcecode type="yangtree"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-udp-client module: ietf-udp-client
grouping udp-client: grouping udp-client:
+-- remote-address inet:host +-- remote-address inet:host
+-- remote-port? inet:port-number +-- remote-port? inet:port-number
+-- local-address? inet:ip-address {local-binding}? +-- local-address? inet:ip-address {local-binding}?
+-- local-port? inet:port-number {local-binding}? +-- local-port? inet:port-number {local-binding}?]]></sourcecode>
]]></sourcecode>
<t>The description of these parameters is provided below:</t> <t>The description of these parameters is provided below:</t>
<ul> <ul>
<li>The "remote-address", which is mandatory, may be configured as <li>The "remote-address", which is mandatory, may be configured as
an IPv4 address, an IPv6 address, or a hostname. The resolved addr ess should be an IPv4 address, an IPv6 address, or a hostname. The resolved addr ess should be
compatible with the local address family, if also provided.</li> compatible with the local address family, if also provided.</li>
<li>The "remote-port" is defined with neither a "default" <li>The "remote-port" is defined with neither a "default"
nor a "mandatory" statement. YANG modules using this grouping nor a "mandatory" statement. YANG modules using this grouping
SHOULD refine the grouping with a "default" statement, <bcp14>SHOULD</bcp14> refine the grouping with a "default" stateme
when the port number is well-known (e.g., a port number allocated nt
by IANA), when the port number is well-known (e.g., a port number allocated
or with a "mandatory" statement, if a port number needs to always by IANA)
be configured. or with a "mandatory" statement if a port number needs to always b
This MAY be ignored when the port number is neither e configured.
This <bcp14>MAY</bcp14> be ignored when the port number is neither
well-known nor mandatory to configure, such as might be the case w hen this grouping well-known nor mandatory to configure, such as might be the case w hen this grouping
is used by another grouping.</li> is used by another grouping.</li>
<li>The "local-address", which is enabled by the "local-binding" <li>The "local-address", which is enabled by the "local-binding"
feature, may be configured as feature, may be configured as
an IPv4 address, an IPv6 address, or a wildcard value. an IPv4 address, an IPv6 address, or a wildcard value.
In normal operation, the local and configured remote addresses In normal operation, the local and configured remote addresses
SHOULD be from the same address family. Differences between addres <bcp14>SHOULD</bcp14> be from the same address family. Differences
s families may between address families may
occur in abnormal or error conditions and are therefore allowed to occur in abnormal or error conditions; therefore, they are allowed
be reported.</li> to be reported.</li>
<li>The "local-port", which depends on the "local-binding" <li>The "local-port", which depends on the "local-binding"
feature, is not mandatory. Its default feature, is not mandatory. Its default
value is "0", indicating that the operating system can select an value is "0", indicating that the operating system can select an
arbitrary port number.</li> arbitrary port number.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="example-client">
<section anchor="example-client" title="Example Usage"> <name>Example Usage</name>
<t>This section presents an example of usage of the "udp-client" <t>This section presents an example of usage of the "udp-client"
grouping.</t> grouping.</t>
<sourcecode type="xml"><![CDATA[ <sourcecode type="xml"><![CDATA[
<!-- The outermost element below doesn't exist in the data model. --> <!-- The outermost element below doesn't exist in the data model. -->
<!-- It simulates if the "grouping" were a "container" instead. --> <!-- It simulates if the "grouping" were a "container" instead. -->
<udp-client xmlns="urn:ietf:params:xml:ns:yang:ietf-udp-client"> <udp-client xmlns="urn:ietf:params:xml:ns:yang:ietf-udp-client">
<remote-address>www.example.com</remote-address> <remote-address>www.example.com</remote-address>
<remote-port>10000</remote-port> <remote-port>10000</remote-port>
<local-address>192.0.2.2</local-address> <local-address>192.0.2.2</local-address>
<local-port>12345</local-port> <local-port>12345</local-port>
</udp-client> </udp-client>]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="udp-client-ym">
<name>YANG Module</name>
<section anchor="udp-client-ym" title="YANG Module"> <!--[rfced] We had the following questions related to the YANG modules
<t>This module imports types defined in <xref target="I-D.ietf-netmod-rf in Sections 2.3 and 3.3:
c6991-bis"/>.</t>
<sourcecode name="ietf-udp-client@2025-12-16.yang" type="yang" markers=" a) FYI - We see that Kent Watson is not listed as an author on the
true"><![CDATA[ module. We will assume this was intentional unless we hear otherwise.
b) We have made slight updates to the format of the modules with pyang
(e.g., indentation and whitespace). Please review in the text output
and confirm.
-->
<t>This module imports types defined in <xref target="RFC9911"/>.</t>
<sourcecode name="ietf-udp-client@2026-05-13.yang" type="yang" markers="
true"><![CDATA[
module ietf-udp-client { module ietf-udp-client {
yang-version 1.1; yang-version 1.1;
namespace namespace "urn:ietf:params:xml:ns:yang:ietf-udp-client";
"urn:ietf:params:xml:ns:yang:ietf-udp-client";
prefix udpc; prefix udpc;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 9911: Common YANG Data Types"; "RFC 9911: Common YANG Data Types";
} }
organization "IETF NETCONF (Network Configuration) Working Group"; organization
"IETF NETCONF (Network Configuration) Working Group";
contact contact
"WG Web: <https://datatracker.ietf.org/group/netconf/> "WG Web: <https://datatracker.ietf.org/group/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Authors: Alex Huang Feng Authors: Alex Huang Feng
<mailto:alex.huang-feng@insa-lyon.fr> <mailto:alex.huang-feng@insa-lyon.fr>
Pierre Francois Pierre Francois
<mailto:pierre.francois@insa-lyon.fr>"; <mailto:pierre.francois@insa-lyon.fr>";
description description
"Defines a generic grouping for UDP-based client applications. "Defines a generic grouping for UDP-based client applications.
Copyright (c) 2025 IETF Trust and the persons identified as Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or
modification, is permitted pursuant to, and subject to the license without modification, is permitted pursuant to, and subject to
terms contained in, the Revised BSD License set forth in Section the license terms contained in, the Revised BSD License set
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents forth in Section 4.c of the IETF Trust's Legal Provisions
(https://trustee.ietf.org/license-info). Relating to IETF Documents
(https://trustee.ietf.org/license-info).
All revisions of IETF and IANA published modules can be found All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters). (https://www.iana.org/assignments/yang-parameters).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9984; see
the RFC itself for full legal notices. the RFC itself for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here."; they appear in all capitals, as shown here.";
revision 2025-12-16 { revision 2026-05-13 {
description description
"Initial revision"; "Initial revision";
reference reference
"RFC XXXX: YANG Groupings for UDP Clients and UDP Servers"; "RFC 9984: YANG Groupings for UDP Clients and UDP Servers";
} }
feature local-binding { feature local-binding {
description description
"Indicates that the UDP client supports configuring local "Indicates that the UDP client supports configuring local
bindings (i.e., the local address and local port number) bindings (i.e., the local address and local port number)
for UDP clients."; for UDP clients.";
} }
grouping udp-client { grouping udp-client {
description description
"A reusable grouping for UDP clients. "A reusable grouping for UDP clients.
Note that this grouping uses fairly typical descendant Note that this grouping uses fairly typical descendant
node names such that a stack of 'uses' statements will node names such that a stack of 'uses' statements will
have name conflicts. It is intended that the consuming have name conflicts. It is intended that the consuming
data model will resolve the issue (e.g., by wrapping data model will resolve the issue (e.g., by wrapping
the 'uses' statement in a container called the 'uses' statement in a container called
'udp-client-parameters'). This model purposely does 'udp-client-parameters'). This module purposely does
not do this itself so as to provide maximum flexibility not do this itself so as to provide maximum flexibility
to consuming models."; to consuming models.";
leaf remote-address { leaf remote-address {
type inet:host; type inet:host;
mandatory true; mandatory true;
description description
"The IP address or hostname of the remote UDP server."; "The IP address or hostname of the remote UDP server.";
} }
leaf remote-port { leaf remote-port {
type inet:port-number; type inet:port-number;
description description
"The port number of the remote UDP server."; "The port number of the remote UDP server.";
} }
leaf local-address { leaf local-address {
if-feature "local-binding"; if-feature "local-binding";
type inet:ip-address; type inet:ip-address;
description description
"The local IP address to bind to when sending UDP "The local IP address to bind to when sending UDP
datagrams to the remote server. INADDR_ANY ('0.0.0.0') or datagrams to the remote server. INADDR_ANY ('0.0.0.0') or
INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') may be used INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') may be used
so that the client can bind to any IPv4 or IPv6 address. so that the client can bind to any IPv4 or IPv6 address.
In normal operation, the local and configured In normal operation, the local and configured
remote addresses SHOULD be from the same address family. remote addresses SHOULD be from the same address family.
Differences between address families may occur in Differences between address families may occur in
abnormal or error conditions and are therefore allowed to abnormal or error conditions; therefore, they are allowed to
be reported."; be reported.";
} }
leaf local-port { leaf local-port {
if-feature "local-binding"; if-feature "local-binding";
type inet:port-number; type inet:port-number;
default "0"; default "0";
description description
"The local port number to bind to when sending UDP "The local port number to bind to when sending UDP
datagrams to the remote server. The port number '0', datagrams to the remote server. The port number '0',
which is the default value, indicates that any available which is the default value, indicates that any available
local port number may be used."; local port number may be used.";
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="udp-server">
<section anchor="udp-server" title='The "ietf-udp-server" Module'> <name>The "ietf-udp-server" Module</name>
<t>This section defines a YANG 1.1 module called "ietf-udp-server". <t>This section defines a YANG 1.1 module called "ietf-udp-server".
This YANG module defines the "udp-server" grouping for This YANG module defines the "udp-server" grouping for
managing UDP servers.</t> managing UDP servers.</t>
<t><xref target="udp-server-overview"/> provides an overview of the <t><xref target="udp-server-overview"/> provides an overview of the
"ietf-udp-server" YANG module. An example of usage is illustrated in "ietf-udp-server" YANG module. An example of usage is illustrated in
<xref target="example-server"/> while <xref target="udp-server-ym"/> defin es the YANG <xref target="example-server"/>. <xref target="udp-server-ym"/> defines t he YANG
module itself.</t> module itself.</t>
<section anchor="udp-server-overview">
<section anchor="udp-server-overview" title='Data Model Overview'> <name>Data Model Overview</name>
<t>This section provides an overview of the grouping defined in the <t>This section provides an overview of the grouping defined in the
"ietf-udp-server" module.</t> "ietf-udp-server" module.</t>
<section anchor="udp-server-grouping">
<section anchor="udp-server-grouping" title='The "udp-server" Grouping'> <name>The "udp-server" Grouping</name>
<t>The following tree diagram <xref target="RFC8340"/> illustrates the <t>The following tree diagram <xref target="RFC8340"/> illustrates the
structure of tree structure of
"udp-server" grouping:</t> "udp-server" grouping:</t>
<sourcecode type="yangtree"><![CDATA[ <sourcecode type="yangtree"><![CDATA[
module: ietf-udp-server module: ietf-udp-server
grouping udp-server: grouping udp-server:
+-- local-bind* [local-address] +-- local-bind* [local-address]
+-- local-address inet:ip-address +-- local-address inet:ip-address
+-- local-port? inet:port-number +-- local-port? inet:port-number]]></sourcecode>
]]></sourcecode>
<t>The description of these parameters is provided below:</t> <t>The description of these parameters is provided below:</t>
<ul> <ul>
<li>The "local-address", which is mandatory, may be configured as <li>The "local-address", which is mandatory, may be configured as
an IPv4 address, an IPv6 address, or a wildcard value.</li> an IPv4 address, an IPv6 address, or a wildcard value.</li>
<li>The "local-port" is defined with neither a "default" nor a <li>The "local-port" is defined with neither a "default" nor a
"mandatory" statement. YANG modules using this grouping SHOULD ref "mandatory" statement. YANG modules using this grouping <bcp14>SHO
ine the ULD</bcp14> refine the
grouping with a "default" statement, when the port number is well- grouping with a "default" statement when the port number is well-k
known nown
(e.g., a port number allocated by IANA), or with a "mandatory" sta (e.g., a port number allocated by IANA) or with a "mandatory" stat
tement, ement
if a port number needs to always be configured. This MAY be ignore if a port number needs to always be configured. This <bcp14>MAY</b
d cp14> be ignored
when the port number is neither well-known nor mandatory to config ure, such when the port number is neither well-known nor mandatory to config ure, such
as might be the case when this grouping is used by another groupin g.</li> as might be the case when this grouping is used by another groupin g.</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="example-server">
<section anchor="example-server" title="Example Usage"> <name>Example Usage</name>
<t>This section presents two examples of usage of the "udp-server" <t>This section presents two examples of usage of the "udp-server"
grouping.</t> grouping.</t>
<t>The following shows an example of a server configured for listening
<t>This following shows an example of a server configured for listening
to an IPv4 address:</t> to an IPv4 address:</t>
<sourcecode type="xml"><![CDATA[ <sourcecode type="xml"><![CDATA[
<!-- The outermost element below doesn't exist in the data model. --> <!-- The outermost element below doesn't exist in the data model. -->
<!-- It simulates if the "grouping" were a "container" instead. --> <!-- It simulates if the "grouping" were a "container" instead. -->
<udp-server xmlns="urn:ietf:params:xml:ns:yang:ietf-udp-server"> <udp-server xmlns="urn:ietf:params:xml:ns:yang:ietf-udp-server">
<local-bind> <local-bind>
<local-address>192.0.2.2</local-address> <local-address>192.0.2.2</local-address>
<local-port>49152</local-port> <local-port>49152</local-port>
</local-bind> </local-bind>
</udp-server> </udp-server>]]></sourcecode>
]]></sourcecode>
<t>This following shows an example of a server configured to listen to a n IPv4 and <t>The following shows an example of a server configured for listening t o an IPv4 and
IPv6 together:</t> IPv6 together:</t>
<sourcecode type="xml"><![CDATA[ <sourcecode type="xml"><![CDATA[
<!-- The outermost element below doesn't exist in the data model. --> <!-- The outermost element below doesn't exist in the data model. -->
<!-- It simulates if the "grouping" were a "container" instead. --> <!-- It simulates if the "grouping" were a "container" instead. -->
<udp-server xmlns="urn:ietf:params:xml:ns:yang:ietf-udp-server"> <udp-server xmlns="urn:ietf:params:xml:ns:yang:ietf-udp-server">
<local-bind> <local-bind>
<local-address>192.0.2.2</local-address> <local-address>192.0.2.2</local-address>
<local-port>49152</local-port> <local-port>49152</local-port>
</local-bind> </local-bind>
<local-bind> <local-bind>
<local-address>2001:db8::0</local-address> <local-address>2001:db8::0</local-address>
<local-port>49153</local-port> <local-port>49153</local-port>
</local-bind> </local-bind>
</udp-server> </udp-server>]]></sourcecode>
]]></sourcecode>
</section> </section>
<section anchor="udp-server-ym">
<section anchor="udp-server-ym" title="YANG Module"> <name>YANG Module</name>
<t>The "ietf-udp-server" imports types defined in <xref target="I-D.ietf <t>This module imports types defined in <xref target="RFC9911"/>.</t>
-netmod-rfc6991-bis"/>.</t> <sourcecode name="ietf-udp-server@2026-05-13.yang" type="yang" markers="
true"><![CDATA[
<sourcecode name="ietf-udp-server@2025-12-16.yang" type="yang" markers="
true"><![CDATA[
module ietf-udp-server { module ietf-udp-server {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-udp-server"; namespace "urn:ietf:params:xml:ns:yang:ietf-udp-server";
prefix udps; prefix udps;
import ietf-inet-types { import ietf-inet-types {
prefix inet; prefix inet;
reference reference
"RFC 9911: Common YANG Data Types"; "RFC 9911: Common YANG Data Types";
} }
skipping to change at line 439 skipping to change at line 463
"WG Web: <https://datatracker.ietf.org/group/netconf/> "WG Web: <https://datatracker.ietf.org/group/netconf/>
WG List: <mailto:netconf@ietf.org> WG List: <mailto:netconf@ietf.org>
Authors: Alex Huang Feng Authors: Alex Huang Feng
<mailto:alex.huang-feng@insa-lyon.fr> <mailto:alex.huang-feng@insa-lyon.fr>
Pierre Francois Pierre Francois
<mailto:pierre.francois@insa-lyon.fr>"; <mailto:pierre.francois@insa-lyon.fr>";
description description
"Defines a generic grouping for UDP-based server applications. "Defines a generic grouping for UDP-based server applications.
Copyright (c) 2025 IETF Trust and the persons identified as Copyright (c) 2026 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or
modification, is permitted pursuant to, and subject to the license without modification, is permitted pursuant to, and subject to
terms contained in, the Revised BSD License set forth in Section the license terms contained in, the Revised BSD License set
4.c of the IETF Trust's Legal Provisions Relating to IETF Documents forth in Section 4.c of the IETF Trust's Legal Provisions
(https://trustee.ietf.org/license-info). Relating to IETF Documents
(https://trustee.ietf.org/license-info).
All revisions of IETF and IANA published modules can be found All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters). (https://www.iana.org/assignments/yang-parameters).
This version of this YANG module is part of RFC XXXX; see This version of this YANG module is part of RFC 9984; see
the RFC itself for full legal notices."; the RFC itself for full legal notices.";
revision 2025-12-16 { revision 2026-05-13 {
description description
"Initial revision"; "Initial revision";
reference reference
"RFC XXXX: YANG Groupings for UDP Clients and UDP Servers"; "RFC 9984: YANG Groupings for UDP Clients and UDP Servers";
} }
grouping udp-server { grouping udp-server {
description description
"Provides a reusable grouping for managing UDP servers. "A reusable grouping for managing UDP servers.
Note that this grouping uses fairly typical descendant Note that this grouping uses fairly typical descendant
node names such that a stack of 'uses' statements will node names such that a stack of 'uses' statements will
have name conflicts. It is intended that the consuming have name conflicts. It is intended that the consuming
data model will resolve the issue (e.g., by wrapping data model will resolve the issue (e.g., by wrapping
the 'uses' statement in a container called the 'uses' statement in a container called
'udp-server-parameters'). This model purposely does 'udp-server-parameters'). This module purposely does
not do this itself so as to provide maximum flexibility not do this itself so as to provide maximum flexibility
to consuming models."; to consuming models.";
list local-bind { list local-bind {
key "local-address"; key "local-address";
min-elements 1; min-elements 1;
description description
"A list of bind (listen) points for this server "A list of bind (listen) points for this server
instance. A server instance may have multiple instance. A server instance may have multiple
bind points to support, e.g., the same port number in bind points to support, e.g., the same port number in
different address families or different port numbers different address families or different port numbers
in the same address family."; in the same address family.";
leaf local-address { leaf local-address {
type inet:ip-address; type inet:ip-address;
mandatory true; mandatory true;
description description
"The local IP address to listen on for incoming "The local IP address to listen on for incoming
UDP datagrams. INADDR_ANY ('0.0.0.0') or UDP datagrams. INADDR_ANY ('0.0.0.0') or
INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') may be used INADDR6_ANY ('0:0:0:0:0:0:0:0' a.k.a. '::') may be used
so that the server can listen to any IPv4 or IPv6 address."; so that the server can listen to any IPv4 or IPv6
address.";
} }
leaf local-port { leaf local-port {
type inet:port-number; type inet:port-number;
description description
"The local port number to listen on for incoming UDP "The local port number to listen on for incoming UDP
datagrams."; datagrams.";
} }
} }
} }
} }
skipping to change at line 502 skipping to change at line 528
leaf local-port { leaf local-port {
type inet:port-number; type inet:port-number;
description description
"The local port number to listen on for incoming UDP "The local port number to listen on for incoming UDP
datagrams."; datagrams.";
} }
} }
} }
} }
]]></sourcecode> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="security">
<name>Security Considerations</name>
<section anchor="security" title="Security Considerations"> <!--[rfced] We had the following questions related to the Security
Considerations section:
<t>This section uses the template described in Section 3.7 of a) Please review the following citation mismatch. We have updated to
<xref target="I-D.ietf-netmod-rfc8407bis"/>.</t> match the security considerations template at
https://wiki.ietf.org/group/ops/yang-security-guidelines. Please let
us know any objections.
<t>The "ietf-udp-client" and "ietf-udp-server" YANG modules defines a data Template:
model that is ...have to use a secure transport layer (e.g., SSH [RFC4252],...
In this document:
...have to use a secure transport layer (e.g., SSH [RFC6242],...
b) We have updated the following for consistent pluralization. Please
let us know any objections.
Original:
As such, there are no additional security issues related to the YANG
module that need to be considered.
Current:
As such, there are no additional security issues related to the YANG
modules that need to be considered.
-->
<t>This section uses the template described in <xref section="3.7.1" secti
onFormat="of" target="RFC9907"/>.</t>
<!--DNE begins -->
<t>The "ietf-udp-client" and "ietf-udp-server" YANG modules define a data
model that is
designed to be accessed via YANG-based management protocols, such as designed to be accessed via YANG-based management protocols, such as
NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. Th Network Configuration Protocol (NETCONF) <xref target="RFC6241"/> and REST
ese YANG-based management protocols (1) have to CONF <xref target="RFC8040"/>. These YANG-based management protocols (1) have to
use a secure transport layer (e.g., SSH <xref target="RFC6242"/>, TLS <xre use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xre
f target="RFC8446"/>, and f target="RFC8446"/>, and
QUIC <xref target="RFC9000"/>) and (2) have to use mutual authentication. QUIC <xref target="RFC9000"/>) and (2) have to use mutual authentication.
</t> </t>
<t>The Network Configuration Access Control Model (NACM) <xref target="RFC 8341"/> <t>The Network Configuration Access Control Model (NACM) <xref target="RFC 8341"/>
provides the means to restrict access for particular NETCONF or provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content. RESTCONF protocol operations and content.
</t> </t>
<t>These YANG modules define a set of identities, types, and <t>These YANG modules define a set of identities, types, and
groupings. These nodes are intended to be reused by other YANG groupings. These nodes are intended to be reused by other YANG
modules. The modules by themselves do not expose any data nodes that modules. The modules by themselves do not expose any data nodes that
are writable, data nodes that contain read-only state, or RPCs. are writable, data nodes that contain read-only state, or RPCs.
As such, there are no additional security issues related to As such, there are no additional security issues related to
the YANG module that need to be considered. the YANG modules that need to be considered.
</t> </t>
<t>Modules that use the groupings that are defined in this document <t>Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For should identify the corresponding security considerations. For
example, reusing some of these groupings will expose privacy-related example, reusing some of these groupings will expose privacy-related
information (e.g., 'remote-address', 'remote-port', 'local-address', information (e.g., 'remote-address', 'remote-port', 'local-address',
or 'local-port'). or 'local-port').
<!--DNE Ends-->
</t> </t>
</section> </section>
<section anchor="IANA_Considerations">
<section anchor="IANA_Considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document describes the URIs from IETF <t>This document describes the URIs from the "IETF
XML Registry and the registration of a two new YANG module names</t> XML Registry" and the registration of two new YANG module names.</t>
<section title="URI"> <section>
<t>IANA is requested to assign two new URIs from the <xref <name>The "IETF XML Registry"</name>
target="RFC3688">IETF XML Registry</xref>:</t> <t>IANA has assigned two new URIs from the <xref target="RFC3688">"IETF
XML Registry"</xref>:</t>
<t><figure> <dl spacing="compact" newline="false">
<artwork align="left"><![CDATA[ <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-udp-client</dd>
URI: urn:ietf:params:xml:ns:yang:ietf-udp-client <dt>Registrant Contact:</dt><dd>The IESG.</dd>
Registrant Contact: The IESG. <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
XML: N/A; the requested URI is an XML namespace.]]></artwork> </dl>
</figure></t> <dl spacing="compact" newline="false">
<dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-udp-server</dd>
<t><figure> <dt>Registrant Contact:</dt><dd>The IESG.</dd>
<artwork align="left"><![CDATA[ <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.</dd>
URI: urn:ietf:params:xml:ns:yang:ietf-udp-server </dl>
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.]]></artwork>
</figure></t>
</section> </section>
<section>
<section title="YANG Module Name"> <name>The "YANG Module Names" Registry</name>
<t>This document also requests IANA to register the following YANG modul <t>IANA has registered the following YANG modules in the
es in the <xref target="RFC6020">"YANG Module Names" registry</xref> within the "Y
<xref target="RFC6020">YANG Module Names registry</xref> within the "YAN ANG Parameters"
G Parameters"
registry group:</t> registry group:</t>
<dl spacing="compact" newline="false">
<t><figure> <dt>Name:</dt><dd>ietf-udp-client</dd>
<artwork align="left"><![CDATA[ <dt>Maintained by IANA?</dt><dd>N</dd>
name: ietf-udp-client <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-udp-client</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-udp-client <dt>Prefix:</dt><dd>udpc</dd>
prefix: udpc <dt>Reference:</dt><dd>RFC 9984</dd>
maintained by IANA? N </dl>
reference: RFC XXXX]]></artwork> <dl spacing="compact" newline="false">
</figure></t> <dt>Name:</dt><dd>ietf-udp-server</dd>
<dt>Maintained by IANA?</dt><dd>N</dd> <dt>Namespace:</dt><dd>urn:ietf
<t><figure> :params:xml:ns:yang:ietf-udp-server</dd>
<artwork align="left"><![CDATA[ <dt>Prefix:</dt><dd>udps</dd>
name: ietf-udp-server <dt>Reference:</dt><dd>RFC 9984</dd>
namespace: urn:ietf:params:xml:ns:yang:ietf-udp-server </dl>
prefix: udps
maintained by IANA? N
reference: RFC XXXX]]></artwork>
</figure></t>
</section> </section>
</section> </section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Mohamed Boucadair, Ran Chen, Benoit Cla
ise, Mahesh Jethanandani,
Qiufang Ma, Jürgen Schönwälder, Ketan Talaulikar,
Eric Vyncke, Paul Wouters and Qin Wu for their review and valuable comment
s.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC <name>References</name>
.768.xml"/> <references>
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC <name>Normative References</name>
.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC 68.xml"/>
.3688.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC 119.xml"/>
.6020.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<xi:include href="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D 688.xml"/>
.ietf-netmod-rfc6991-bis.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC 020.xml"/>
.7950.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC 911.xml"/>
.8341.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC 950.xml"/>
.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</references> 341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references>
<references>
<name>Informative References</name>
<!-- [I-D.ietf-netmod-rfc8407bis] now RFC 9907
-->
<references title="Informative References"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9907.xml
<xi:include href="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D "/>
.ietf-netmod-rfc8407bis.xml"/>
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC
.6241.xml"/>
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC
.6242.xml"/>
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC
.8040.xml"/>
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC
.8259.xml"/>
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC
.8340.xml"/>
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC
.8342.xml"/>
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC
.8446.xml"/>
<xi:include href="https://xml.resource.org/public/rfc/bibxml/reference.RFC
.9000.xml"/>
<reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/200 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4252.xm
8/REC-xml-20081126/" quoteTitle="true" derivedAnchor="W3C.REC-xml-20081126"> l"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
241.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
259.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
342.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
000.xml"/>
<reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/2
008/REC-xml-20081126/" quoteTitle="true" derivedAnchor="W3C.REC-xml-20081126">
<front> <front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title> <title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials="T." surname="Bray" fullname="Tim Bray"/> <author initials="T." surname="Bray" fullname="Tim Bray" role="edito
<author initials="J." surname="Paoli" fullname="Jean Paoli"/> r"/>
<author initials="C.M." surname="Sperberg-McQueen" fullname="C. M. S <author initials="J." surname="Paoli" fullname="Jean Paoli" role="ed
perberg-McQueen"/> itor"/>
<author initials="E." surname="Maler" fullname="Eve Maler"/> <author initials="C.M." surname="Sperberg-McQueen" fullname="C. M. S
<author initials="F." surname="Yergeau" fullname="François Yergeau"/ perberg McQueen" role="editor"/>
> <author initials="E." surname="Maler" fullname="Eve Maler" role="edi
<date month="November" year="2008"/> tor"/>
<author initials="F." surname="Yergeau" fullname="Francois Yergeau"
role="editor"/>
<date day="26" month="November" year="2008"/>
</front> </front>
<seriesInfo name="World Wide Web Consortium Recommendation" value="REC <refcontent>W3C Recommendation</refcontent>
-xml-20081126"/> <annotation>Latest version available at <eref brackets="angle" target=
"https://www.w3.org/TR/xml/"/>.</annotation>
</reference> </reference>
</references>
</references> </references>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Mohamed
Boucadair"/>, <contact fullname="Ran Chen"/>, <contact fullname="Benoit
Claise"/>, <contact fullname="Mahesh Jethanandani"/>, <contact
fullname="Qiufang Ma"/>, <contact fullname="Jürgen Schönwälder"/>,
<contact fullname="Ketan Talaulikar"/>, <contact fullname="Éric
Vyncke"/>, <contact fullname="Paul Wouters"/>, and <contact
fullname="Qin Wu"/> for their reviews and valuable comments.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 106 change blocks. 
327 lines changed or deleted 390 lines changed or added

This html diff was produced by rfcdiff 1.48.