YANG Data Models for Security Configuration Check
draft-hu-opsawg-sec-config-yang-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Feifei Hu , Yu HUANG , Lei YAN | ||
| Last updated | 2024-10-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hu-opsawg-sec-config-yang-00
opsawg F. Hu
Internet-Draft Y. Huang
Intended status: Standards Track China Southern Power Grid
Expires: 24 April 2025 L. Yan
Huawei Technologies
21 October 2024
YANG Data Models for Security Configuration Check
draft-hu-opsawg-sec-config-yang-00
Abstract
Security configuration refers to the status setting of product
security features/functions to reduce network security risks during
product use. This document defines YANG data models for the security
configuration check.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Hu, et al. Expires 24 April 2025 [Page 1]
Internet-Draft YANG Data Models for Security Configurat October 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.3. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
2. Categorization of Security Configurations . . . . . . . . . . 3
2.1. Weak Algorithms . . . . . . . . . . . . . . . . . . . . . 4
2.2. Insecure Protocols . . . . . . . . . . . . . . . . . . . 5
2.3. Insecure Features Status . . . . . . . . . . . . . . . . 7
2.4. Short Key length . . . . . . . . . . . . . . . . . . . . 10
2.5. Unchanged Default Settings . . . . . . . . . . . . . . . 12
3. YANG Data Model for Security Configuration Check . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Weak or incorrect configurations are the main factors of network
insecurity. Insecure configurations can be exploited to easily
launch a network intrusion by attackers. It is reported that more
than 95 per cent of the attacks are successful because of missing
software updates or bad system configurations. The top 3 high-risk
configuration items are default password, unnecessary opened ports,
and insecure protocol or algorithm. The default accounts and
passwords make it easy for attackers to guess and successfully access
the network. The unnecessary opened ports increase the exposed
surface of the attack. Although security protocols can improve
security, using known vulnerable algorithms or protocol versions will
greatly reduce the attack difficulty.
Security configuration checks can reduce network security risks
during the usage of devices. The first step of the security
configuration check is to collect security configuration information
from devices. Then, the value of the collected configuration item
will be compared with the security configuration benchmark to
determine whether the configuration item is secure. The security
configuration benchmark is the recommended value of the configuration
item to ensure basic device security.
Hu, et al. Expires 24 April 2025 [Page 2]
Internet-Draft YANG Data Models for Security Configurat October 2024
In the past, the IETF has existing work on security posture
definition, collection, and assessment, including the concluded
Network Endpoint Assessment (NEA)[RFC5209] and Security Automation
and Continuous Monitoring (SACM) working groups [RFC8248]. The
security configuration benchmark of the management plane
[I-D.lin-sacm-nid-mp-security-baseline] has been defined in SACM.
This document focuses on the first step of the security configuration
check and defines YANG data models for security configurations to be
collected. In this document, the security configuration check will
be categorized first. Second, the YANG data models will be built
according to the categories.
1.1. Terminology
1.2. Requirements Language
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.3. Tree Diagrams
The meaning of the symbols in this diagram is defined in [RFC8340].
2. Categorization of Security Configurations
Figure 1 depicts the categorization of the security configuration
check:
+-----------------------------+
| Security Configuration Check|
+---------------+-------------+
|
+-------------+------------+-----------+-----------+
| | | | |
| | | | |
| | | | |
+-----v-----+ +-----v----+ +-----v----+ +----v---+ +-----v-----+
| Weak | | Insecure | | Insecure | | Short | | Unchanged |
| Algorithm | | Protocol | | Features | | Key | | Default |
+-----------+ +----------+ | Status | | Length | | Settings |
+----------+ +--------+ +-----------+
Figure 1: Categorization of Security Configuration Check
Hu, et al. Expires 24 April 2025 [Page 3]
Internet-Draft YANG Data Models for Security Configurat October 2024
The security configuration check is categorized into weak algorithms,
insecure protocols, insecure feature status, short key length and
unchanged default settings.
2.1. Weak Algorithms
Here, algorithms refer to any algorithms used in any softwares or
protocols for security purpose, such as key exchange, encryption,
signature, and integrity check. The weak algorithms are the
algorithms that is considered insecure, such as MD5, 3DES.
Take TLS as an example, security algorithms used in TLS are called
cipher-suites.
With the existing definitions of YANG Groupings for TLS Clients and
TLS Servers [RFC9645], the algorithms supported by TLS can be
retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as the
following example:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<get-data
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:operational</datastore>
<subtree-filter>
<hello-params
xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-common"
xmlns:tlscmn="urn:ietf:params:xml:ns:yang:ietf-tls-common">
<cipher-suites>
<cipher-suite>
<cipher-suite/>
</cipher-suite>
</cipher-suites>
</hello-params>
</subtree-filter>
</get-data>
</rpc>
In addition, the real-time change of the above information can be
notified on time with NETCONF pub/sub mechanisms [RFC8641] as the
following example:
Hu, et al. Expires 24 April 2025 [Page 4]
Internet-Draft YANG Data Models for Security Configurat October 2024
<netconf:rpc xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</yp:datastore>
<yp:datastore-subtree-filter>
<hello-params
xmlns="urn:ietf:params:xml:ns:yang:ietf-tls-common"
xmlns:tlscmn="urn:ietf:params:xml:ns:yang:ietf-tls-common">
<cipher-suites>
<cipher-suite>
<cipher-suite/>
</cipher-suite>
</cipher-suites>
</hello-params>
</yp:datastore-subtree-filter>
<yp:on-change/>
</establish-subscription>
</netconf:rpc>
2.2. Insecure Protocols
Here, protocols refer to any protocol used in a device for the
communication to any other devices in any layers. Insecure protocols
can be the protocol without security mechanisms, such as TCP and
HTTP, or the older version of the protocols, such as TLSv1.1 and
SNMPv1.
Common Protocols and their YANG models are listed as follows:
Hu, et al. Expires 24 April 2025 [Page 5]
Internet-Draft YANG Data Models for Security Configurat October 2024
+===========+=======================================+
| Protocols | YANG models |
+===========+=======================================+
| TLS/DTLS | [RFC9645] |
+-----------+---------------------------------------+
| SNMP | [RFC7407] |
+-----------+---------------------------------------+
| SSH | [RFC9644] |
+-----------+---------------------------------------+
| IPsec | [RFC9061] |
+-----------+---------------------------------------+
| HTTP | [I-D.ietf-netconf-http-client-server] |
+-----------+---------------------------------------+
| TCP | [RFC9648] |
+-----------+---------------------------------------+
| UDP | [I-D.ietf-netconf-udp-client-server] |
+-----------+---------------------------------------+
Table 1: Common Protocols and Their YANG Models
Take SNMP as an example. With the existing definitions of a YANG
data model for SNMP configuration [RFC7407], the protocol version of
SNMP can be retrieved with NETCONF [RFC6241] Subtree Filtering
mechanism as the following example:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<get-data
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:operational</datastore>
<subtree-filter>
<snmp
xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
<engine>
<version>
<version/>
</version>
</engine>
</snmp>
</subtree-filter>
</get-data>
</rpc>
In addition, the real-time change of the above information can be
notified on time with NETCONF pub/sub mechanisms [RFC8641] as the
following example:
Hu, et al. Expires 24 April 2025 [Page 6]
Internet-Draft YANG Data Models for Security Configurat October 2024
<netconf:rpc xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</yp:datastore>
<yp:datastore-subtree-filter>
<snmp
xmlns="urn:ietf:params:xml:ns:yang:ietf-snmp">
<engine>
<version>
<version/>
</version>
</engine>
</snmp>
</yp:datastore-subtree-filter>
<yp:on-change/>
</establish-subscription>
</netconf:rpc>
2.3. Insecure Features Status
Security features include security functions and configurations.
Insecure features are classified as follows:
* all interfaces listening
* all interfaces binding
* unconfigured security configurations
- unconfigured ACL hardening
- unconfigured keys
- unconfigured passwords
- unconfigured timeout period
* disabled security functions
- disabled account locking
- disabled certificate verification
Hu, et al. Expires 24 April 2025 [Page 7]
Internet-Draft YANG Data Models for Security Configurat October 2024
- disabled allowlitst
- disabled blocklist
- disabled encryption function
- disabled authentication function
- disabled security protocol
Listening or binding all interfaces may cause the exposed attack
surface to increase. Setting the security configurations and
enabling the security functions will enhance the device's security.
The submodule "ietf-security-config-features", which defines the
configuration parameters of security features, has the following
structure:
submodule: ietf-security-config-features
+--rw security cofig
+--rw security features* [name]
+--rw id? unit64
+--rw name string
+--rw description? string
+--rw status boolean
The "status" true means the security feature is enabled or
configured, and false means the security feature is disabled or
unconfigured.
The submodel "ietf-security-config-features" can be used with NETCONF
[RFC6241] Subtree Filtering mechanism for configuration information
collection. The feature status information can be retrieved with
NETCONF [RFC6241] Subtree Filtering mechanism as the following
example:
Hu, et al. Expires 24 April 2025 [Page 8]
Internet-Draft YANG Data Models for Security Configurat October 2024
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<get-data
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:operational</datastore>
<subtree-filter>
<security-config
xmlns="urn:ietf:params:xml:ns:yang:ietf-security-config">
<security features>
<name>
<name/>
</name>
<status>
<status/>
</status>
</security features>
</security-config>
</subtree-filter>
</get-data>
</rpc>
In addition, the real-time change of the above information can be
notified on time with NETCONF pub/sub mechanisms [RFC8641] as the
following example:
Hu, et al. Expires 24 April 2025 [Page 9]
Internet-Draft YANG Data Models for Security Configurat October 2024
<netconf:rpc xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</yp:datastore>
<yp:datastore-subtree-filter>
<security-config
xmlns="urn:ietf:params:xml:ns:yang:ietf-security-config">
<security features>
<name>
<name/>
</name>
<status>
<status/>
</status>
</security features>
</security-config>
</yp:datastore-subtree-filter>
<yp:on-change/>
</establish-subscription>
</netconf:rpc>
2.4. Short Key length
Short Key length means the key is not long enough to meet the
security requirement. The submodule "ietf-security-config-key",
which defines configuration parameters of key length, has the
following structure:
submodule: ietf-security-config-key
+--rw security cofig
+--rw key* [key id]
+--rw key id unit64
+--rw usage? string
+--rw length unit64
The "usage" describes the key is used by which algorithm of which
protocol or software.
The submodel "ietf-security-config-key" can be used with NETCONF
[RFC6241] Subtree Filtering mechanism for configuration information
collection. The key length information can be retrieved with NETCONF
[RFC6241] Subtree Filtering mechanism as the following example:
Hu, et al. Expires 24 April 2025 [Page 10]
Internet-Draft YANG Data Models for Security Configurat October 2024
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<get-data
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:operational</datastore>
<subtree-filter>
<security-config
xmlns="urn:ietf:params:xml:ns:yang:ietf-security-config">
<key>
<key id>
<key id/>
</key id>
<length>
<length/>
</length>
</key>
</security-config>
</subtree-filter>
</get-data>
</rpc>
In addition, the real-time change of the above information can be
notified on time with NETCONF pub/sub mechanisms [RFC8641] as the
following example:
Hu, et al. Expires 24 April 2025 [Page 11]
Internet-Draft YANG Data Models for Security Configurat October 2024
<netconf:rpc xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</yp:datastore>
<yp:datastore-subtree-filter>
<security-config
xmlns="urn:ietf:params:xml:ns:yang:ietf-security-config">
<key>
<key id>
<key id/>
</key id>
<length>
<length/>
</length>
</key>
</yp:datastore-subtree-filter>
<yp:on-change/>
</establish-subscription>
</netconf:rpc>
2.5. Unchanged Default Settings
Default settings required to be changed include the default security-
related configurations set by manufacturers and the default port
defined by protocols. Unchanged default settings are classified as
follows:
* Unchanged default certificates
* Unchanged default PKI domains
* Unchanged default keys
* Unchanged default ports
Using the default certificates, PKI domains, or keys set by
manufacturers may have a risk of being cracked. Using the default
port number of a protocol may cause being sniffed and monitored.
The submodule "ietf-security-config-default-settings", which defines
configuration parameters of default settings, has the following
structure:
Hu, et al. Expires 24 April 2025 [Page 12]
Internet-Draft YANG Data Models for Security Configurat October 2024
submodule: ietf-security-config-default-settings
+--rw security cofig
+--rw default settings* [name]
+--rw type enumeration
{certificates, PKI domains, keys, ports}
+--rw id? unit64
+--rw name string
+--rw description? string
+--rw changed boolean
The "changed" true means the default setting has been changed, and
false means unchanged.
The submodel "ietf-security-config-default-settings" can be used with
NETCONF [RFC6241] Subtree Filtering mechanism for configuration
information collection. The default setting information can be
retrieved with NETCONF [RFC6241] Subtree Filtering mechanism as the
following example:
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<get-data
xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
<datastore>ds:operational</datastore>
<subtree-filter>
<security-config
xmlns="urn:ietf:params:xml:ns:yang:ietf-security-config">
<default settings>
<type>
<type/>
</type>
<name>
<name/>
</name>
<changed>
<changed/>
</changed>
</default settings>
</security-config>
</subtree-filter>
</get-data>
</rpc>
In addition, the real-time change of the above information can be
notified on time with NETCONF pub/sub mechanisms [RFC8641] as the
following example:
Hu, et al. Expires 24 April 2025 [Page 13]
Internet-Draft YANG Data Models for Security Configurat October 2024
<netconf:rpc xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<establish-subscription
xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push">
<yp:datastore
xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
ds:operational
</yp:datastore>
<yp:datastore-subtree-filter>
<security-config
xmlns="urn:ietf:params:xml:ns:yang:ietf-security-config">
<default settings>
<type>
<type/>
</type>
<name>
<name/>
</name>
<changed>
<changed/>
</changed>
</default settings>
</yp:datastore-subtree-filter>
<yp:on-change/>
</establish-subscription>
</netconf:rpc>
3. YANG Data Model for Security Configuration Check
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/rfc/rfc8340>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/rfc/rfc6241>.
Hu, et al. Expires 24 April 2025 [Page 14]
Internet-Draft YANG Data Models for Security Configurat October 2024
[RFC7407] Bjorklund, M. and J. Schoenwaelder, "A YANG Data Model for
SNMP Configuration", RFC 7407, DOI 10.17487/RFC7407,
December 2014, <https://www.rfc-editor.org/rfc/rfc7407>.
[RFC9645] Watsen, K., "YANG Groupings for TLS Clients and TLS
Servers", RFC 9645, DOI 10.17487/RFC9645, October 2024,
<https://www.rfc-editor.org/rfc/rfc9645>.
[RFC9644] Watsen, K., "YANG Groupings for SSH Clients and SSH
Servers", RFC 9644, DOI 10.17487/RFC9644, October 2024,
<https://www.rfc-editor.org/rfc/rfc9644>.
[RFC9648] Scharf, M., Jethanandani, M., and V. Murgai, "YANG Data
Model for TCP", RFC 9648, DOI 10.17487/RFC9648, October
2024, <https://www.rfc-editor.org/rfc/rfc9648>.
[RFC9061] Marin-Lopez, R., Lopez-Millan, G., and F. Pereniguez-
Garcia, "A YANG Data Model for IPsec Flow Protection Based
on Software-Defined Networking (SDN)", RFC 9061,
DOI 10.17487/RFC9061, July 2021,
<https://www.rfc-editor.org/rfc/rfc9061>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
6.2. Informative References
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J.
Tardo, "Network Endpoint Assessment (NEA): Overview and
Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008,
<https://www.rfc-editor.org/rfc/rfc5209>.
[RFC8248] Cam-Winget, N. and L. Lorenzin, "Security Automation and
Continuous Monitoring (SACM) Requirements", RFC 8248,
DOI 10.17487/RFC8248, September 2017,
<https://www.rfc-editor.org/rfc/rfc8248>.
[RFC8641] Clemm, A. and E. Voit, "Subscription to YANG Notifications
for Datastore Updates", RFC 8641, DOI 10.17487/RFC8641,
September 2019, <https://www.rfc-editor.org/rfc/rfc8641>.
Hu, et al. Expires 24 April 2025 [Page 15]
Internet-Draft YANG Data Models for Security Configurat October 2024
[I-D.lin-sacm-nid-mp-security-baseline]
Lin, Q., Xia, L., and H. Birkholz, "The Data Model of
Network Infrastructure Device Management Plane Security
Baseline", Work in Progress, Internet-Draft, draft-lin-
sacm-nid-mp-security-baseline-04, 22 October 2018,
<https://datatracker.ietf.org/doc/html/draft-lin-sacm-nid-
mp-security-baseline-04>.
[I-D.ietf-netconf-http-client-server]
Watsen, K., "YANG Groupings for HTTP Clients and HTTP
Servers", Work in Progress, Internet-Draft, draft-ietf-
netconf-http-client-server-23, 15 August 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
http-client-server-23>.
[I-D.ietf-netconf-udp-client-server]
Feng, A. H., Francois, P., and K. Watsen, "YANG Groupings
for UDP Clients and UDP Servers", Work in Progress,
Internet-Draft, draft-ietf-netconf-udp-client-server-05,
17 October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-netconf-udp-client-server-05>.
Acknowledgements
Contributors
Xubin LIN
China Southern Power Grid
linxb2@csg.cn
Authors' Addresses
Feifei HU
China Southern Power Grid
Email: huff@csg.cn
Yu HUANG
China Southern Power Grid
Email: huangyu@csg.cn
Lei YAN
Huawei Technologies
Email: ray.yanlei@huawei.com
Hu, et al. Expires 24 April 2025 [Page 16]