RFC 9764
Bidirectional Forwarding Detection (BFD) Encapsulated in Large Packets
Bidirectional Forwarding Detection (BFD) Encapsulated in Large Packets 🎀
okay bestie, RFC 9764 is titled "Bidirectional Forwarding Detection (BFD) Encapsulated in Large Packets" and it's a Standards Track doc from April 2025 🌸 The authors are J. Haas at Juniper Networks, Inc. and A. Fu at Bloomberg L.P. It's ISSN 2070-1721 and the IETF published it as RFC 9764. Its title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨
Abstract 💖
okay so BFD is the protocol everyone uses to check that two systems can actually talk to each other 🫶 BFD packets are usually super tiny. Sometimes you want to know more than "the path is up." You want to know the path can carry a payload of a specific size 👀 This document explains how to do that with BFD running in Asynchronous mode 🦋
It also defines YANG modules for managing this mechanism. These modules augment the existing BFD YANG modules from RFC 9314 💅 They follow the Network Management Datastore Architecture (NMDA) from RFC 8342, which is giving organized and I'm here for it 🧚
Status of This Memo 📜
This is an Internet Standards Track document ✨
It's a product of the Internet Engineering Task Force (IETF), so it reflects what the IETF community agrees on. It went through public review and the Internet Engineering Steering Group (IESG) approved it for publication 🔥 If you want more on Internet Standards, check Section 2 of RFC 7841.
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9764 🌈
Copyright Notice 🌸
Copyright (c) 2025 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, which you can find at https://trustee.ietf.org/license-info as of the publication date. Please actually read these, bestie, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They also come with no warranty, same as the Revised BSD License says 💅
Table of Contents 📑
1. Introduction
2. Requirements Language
3. BFD Encapsulated in Large Packets
4. Implementation and Deployment Considerations
4.1. Implementations That Do Not Support Large BFD Packets
4.2. Selecting MTU Size To Be Detected
4.3. Detecting MTU Mismatches
4.4. Detecting MTU Changes
4.5. Equal-Cost Multipath (ECMP) or Other Load-Balancing
Considerations
4.6. S-BFD
5. BFD Encapsulated in Large Packets YANG Module
5.1. Data Model Overview
5.2. YANG Module
6. Security Considerations
6.1. YANG Security Considerations
7. IANA Considerations
7.1. The "IETF XML" Registry
7.2. The "YANG Module Names" Registry
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction ✨
okay so BFD [RFC5880] is the go-to for checking connectivity between two systems 💖 But some apps need more. They might need the Path MTU [RFC1191] between those two systems to hit a minimum size. If the Path MTU drops below that threshold, those apps may decide the path isn't usable 😭
BFD can ride inside a bunch of different transport protocols. One example is single-hop BFD [RFC5881] 🦋 With single-hop, the link MTU config is usually enough to guarantee the two systems can talk at that MTU size. BFD Echo mode (Section 6.4 of [RFC5880]) is also enough to verify the Path MTU of directly connected systems, so it's giving reliable 💅 People have already floated proposals for testing Path MTU on directly connected systems, like [BFD-ECHO-PATH-MTU] 🧚 Multihop BFD [RFC5883] is a different story though. That guarantee just doesn't hold there 💀
Multihop BFD sessions are encapsulated in a simple UDP packet 🌈 The BFD elements of procedure (Section 6.8.6 of [RFC5880]) cover validating the BFD payload. But the spec says nothing about how long the encapsulation carrying the BFD PDU is supposed to be 🙈 It's most common for the transport protocol payload (that's UDP) length to match the BFD PDU size exactly. The elements of procedure don't require that though, so the transport length could end up bigger than the BFD PDU it's carrying 👀
2. Requirements Language 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are the BCP 14 [RFC2119] [RFC8174] key words. They only mean what BCP 14 says when they show up in all capitals, exactly like this 💅
3. BFD Encapsulated in Large Packets 🌸
Support for BFD between two systems usually gets configured, even if a client protocol is the one that actually spins up the session dynamically ✨ This document adds one new BFD variable:
bfd.PaddedPduSizeThe BFD transport protocol payload size (in bytes) gets bumped up to this value. The contents of this extra payload MUST be zero 🫶 The receiver SHOULD NOT validate the contents of this additional payload 🙈 The minimum size of this variable MUST NOT be smaller than 24 or 26 bytes, which the BFD procedure permits. See Section 6.8.6 of [RFC5880] for that bit 🔥
Also, when you're using IPv4 encapsulation, the Don't Fragment bit (Section 2.3 of [RFC0791]) in the IP payload MUST be set 👑
4. Implementation and Deployment Considerations 🧚
4.1. Implementations That Do Not Support Large BFD Packets 💀
Okay so this document doesn't change BFD itself 🦋 But implementations might not let arbitrarily padded transport PDUs carry BFD packets. Section 6 of [RFC5880] warns against being excessively pedantic, but an implementation may still not work with this mechanism without extra support 🙄
Section 6.8.6 of [RFC5880] covers how to receive BFD Control packets 🌈 The length of a BFD Control packet gets checked to make sure it's less than or equal to the payload of the encapsulating protocol. If a receiving implementation can't handle large BFD packets, it could go wrong in one of two ways:
- A receiving BFD implementation can't accept large BFD packets at all. That's the same as the packet getting discarded.
- A receiving BFD implementation can accept large BFD packets, but the Control packet gets wrongly rejected during validation. That's also the same as the packet getting discarded.
In both cases the BFD state machine acts like it isn't getting Control packets at all 😭 The receiving implementation then follows its normal BFD procedures for when it hasn't received Control packets.
If large BFD packets get enabled on a session that's already Up, and the remote BFD system doesn't (or can't) receive the padded BFD control packets, the session goes Down 💔
4.2. Selecting MTU Size To Be Detected 🎀
Since we're talking about Path MTU, BFD sessions using this feature only need an appropriate bfd.PaddedPduSize value to exercise the Path MTU for whatever application they care about 💖 That value can be way smaller than the system's link MTU. For example, the desired Path MTU might be 1512 bytes while the interface MTU that BFD with large packets runs on is 9000 bytes 🦋
If multiple BFD clients want to test the same BFD endpoints with different bfd.PaddedPduSize parameters, implementations SHOULD select the largest bfd.PaddedPduSize from the configured sessions 👑 This is similar to how BFD implementations pick the most aggressive timing parameters when there are multiple sessions to the same endpoint 🧚 If you don't select the largest size, the BFD sessions will go to the Up state, but dependent applications won't get their MTU requirements satisfied 😭
4.3. Detecting MTU Mismatches 🌈
The MTU an interface accepts gets affected by packet encapsulation at a given layer, like Layer 2, Layer 3, tunnels, and so on 🙈 A super common misconfig is inconsistent MTU. When the MTU is inconsistent, applications can end up with unidirectional connectivity 💀
If an application using BFD with Large Packets needs to test the bidirectional Path MTU, you have to configure bfd.PaddedPduSize on each side of the BFD session 🫶 For example, say you want to verify a 1512-byte MTU in both directions on an Ethernet or point-to-point link. Then each side of the BFD session has to have bfd.PaddedPduSize set to 1512 💅 Without that consistent config, BFD with Large Packets may correctly figure out unidirectional connectivity at the tested MTU, but the bidirectional MTU might not get validated properly 👀
It should be noted that some interfaces may intentionally have different MTUs. Setting bfd.PaddedPduSize appropriately on each side of the BFD session supports those scenarios too ✨
4.4. Detecting MTU Changes 🦋
Once BFD sessions using Large Packets reach the Up state, connectivity at the tested MTU(s) for that session is being validated 🔥 If the Path MTU tested by the BFD with Large Packets session drops below the tested MTU, the BFD session goes Down 💔
The opposite case is when the Path MTU goes up. Then the BFD session keeps going without any impact 🌸 BFD for Large Packets just makes sure the minimally acceptable MTU for the session can still be used 💖
4.5. Equal-Cost Multipath (ECMP) or Other Load-Balancing Considerations ✨
Okay so, networks have a bunch of tricks to make throughput between two endpoints go brrr at different layers 🚀. Stuff like Link Aggregation Groups (LAGs) or ECMP forwarding. These balance traffic across multiple physical links and hide all the balancing details from the higher networking layers 🙈. Those details are super implementation-specific.
Now, with load balancing in the mix, it's possible to have member links that aren't properly forwarding traffic 💀. When traffic gets picked to be load balanced across one of those broken members, it gets dropped.
Here's the tea 🫖: these load-balancing mechanisms may not let every link member get properly tested by BFD 😭. That's because BFD Control packets may be forwarded only along links that are up. BFD on LAG interfaces, [RFC7130], was developed to help cover one of these scenarios 🎀. But for testing forwarding over multiple hops, there's no general-purpose BFD mechanism specified for exercising all the links in an ECMP 🥺. The result? A BFD session can be in the Up state while some traffic is getting dropped or otherwise negatively impacted along some component links 😬.
Some BFD implementations use their own internal understanding of the component links and their resulting forwarding, so they can exercise BFD in a way that better tests the ECMP members and ties the BFD session state to the health of that ECMP 👑. But since the load balancing is implementation-specific, it's not possible to standardize these additional mechanisms for BFD 🌸.
Also, misconfiguration of some member MTUs may lead to load balancing that has an inconsistent Path MTU depending on how the traffic gets balanced 🙃. The whole point of BFD with large packets is to verify Path MTU, so it's subject to the same considerations above 🫶.
This section applies to most, if not all, BFD techniques 💖.
4.6. S-BFD 🧚
This mechanism can also be applied to other forms of BFD, including Seamless BFD (S-BFD) [RFC7880] 💜.
5. BFD Encapsulated in Large Packets YANG Module 🎀
5.1. Data Model Overview 🌈
Okay, this YANG module augments the "ietf-bfd" module to add a flag 'padding' to turn this feature on 🔥. The feature statement 'padding' needs to be enabled to show that the implementation supports BFD encapsulated in large packets.
The module also augments the YANG modules for single-hop, multihop, LAG, and MPLS to add the "pdu-size" parameter to those session types, so you can configure large BFD packets 📦.
Finally, kinda like the grouping "client-cfg-parms" defined in Section 2.1 of [RFC9314], this YANG module defines a grouping "bfd-large-common" that BFD clients can use with "client-cfg-params" to uniformly add support for the feature defined in this RFC 💖.
module: ietf-bfd-large
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh
/bfd-ip-sh:sessions/bfd-ip-sh:session:
+--rw pdu-size? padded-pdu-size {padding}?
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh
/bfd-ip-mh:session-groups/bfd-ip-mh:session-group:
+--rw pdu-size? padded-pdu-size {padding}?
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-lag:lag
/bfd-lag:sessions/bfd-lag:session:
+--rw pdu-size? padded-pdu-size {padding}?
augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls
/bfd-mpls:session-groups/bfd-mpls:session-group:
+--rw pdu-size? padded-pdu-size {padding}?Figure 1
5.2. YANG Module 💅
This YANG module imports "A YANG Data Model for Routing Management (NMDA Version)" [RFC8349] and "YANG Data Model for Bidirectional Forwarding Detection (BFD)" [RFC9314] 🫶.
<CODE BEGINS> file "ietf-bfd-large@2025-04-04.yang"
module ietf-bfd-large {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-bfd-large";
prefix bfdl;
import ietf-routing {
prefix rt;
reference
"RFC 8349: A YANG Data Model for Routing Management
(NMDA version)";
}
import ietf-bfd {
prefix bfd;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection.";
}
import ietf-bfd-ip-sh {
prefix bfd-ip-sh;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection.";
}
import ietf-bfd-ip-mh {
prefix bfd-ip-mh;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection.";
}
import ietf-bfd-lag {
prefix bfd-lag;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection.";
}
import ietf-bfd-mpls {
prefix bfd-mpls;
reference
"RFC 9314: YANG Data Model for Bidirectional
Forwarding Detection.";
}
organization
"IETF BFD Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/bfd>
WG List: <rtg-bfd@ietf.org>
Authors: Jeffrey Haas (jhaas@juniper.net)
Albert Fu (afu14@bloomberg.net).";
description
"This YANG module augments the base BFD YANG module to add
attributes related to support for BFD Encapsulated in Large
Packets. In particular, it adds a per-session parameter for the
BFD Padded PDU Size.
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 is part of RFC 9764
(https://www.rfc-editor.org/info/rfc9764); 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 2025-04-04 {
description
"Initial Version.";
reference
"RFC 9764, Bidirectional Forwarding Detection (BFD)
Encapsulated in Large Packets.";
}
feature padding {
description
"If supported, the feature allows for BFD sessions to be
configured with padded PDUs in support of BFD Encapsulated in
Large Packets.";
}
typedef padded-pdu-size {
type uint16 {
range "24..65535";
}
units "bytes";
description
"The size of the padded and encapsulated BFD control packets
to be transmitted at Layer 3. The BFD minimum control packet
size is 24 or 26 octets; see Section 6.8.6 of RFC 5880.
If the configured padded PDU size is smaller than the minimum
sized packet of a given BFD session, then the minimum sized
packet for the session will be used.
The maximum padded PDU size may be limited by the supported
interface MTU of the system.";
reference
"RFC 9764, Bidirectional Forwarding Detection (BFD)
Encapsulated in Large Packets.";
}
grouping bfd-large-common {
description
"Common configuration and operational state for BFD
Encapsulated in Large Packets.";
reference
"RFC 9764, Bidirectional Forwarding Detection (BFD)
Encapsulated in Large Packets.";
leaf pdu-size {
if-feature "padding";
type padded-pdu-size;
description
"If set, this configures the padded PDU size for the
Asynchronous mode BFD session. By default, no additional
padding is added to such packets.";
}
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-sh:ip-sh/"
+ "bfd-ip-sh:sessions/bfd-ip-sh:session" {
uses bfd-large-common;
description
"Augment the 'bfd' container to add attributes related to BFD
Encapsulated in Large Packets.";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-ip-mh:ip-mh/"
+ "bfd-ip-mh:session-groups/bfd-ip-mh:session-group" {
uses bfd-large-common;
description
"Augment the 'bfd' container to add attributes related to BFD
Encapsulated in Large Packets.";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-lag:lag/"
+ "bfd-lag:sessions/bfd-lag:session" {
uses bfd-large-common;
description
"Augment the 'bfd' container to add attributes related to BFD
Encapsulated in Large Packets.";
}
augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/bfd:bfd/bfd-mpls:mpls/"
+ "bfd-mpls:session-groups/bfd-mpls:session-group" {
uses bfd-large-common;
description
"Augment the 'bfd' container to add attributes related to BFD
Encapsulated in Large Packets.";
}
}
<CODE ENDS>Figure 2
6. Security Considerations 🔒
Bestie, this part is serious, so read it carefully 🚨.
This document does not change the underlying security considerations of the BFD protocol or its encapsulations 🛡️.
On-path attackers that can selectively drop BFD packets, including those with large MTUs, can cause BFD sessions to go Down 😱. Yikes, that's a whole vibe check.
The contents of the padding payload are set to zero. This avoids implementation issues where the local uninitialized data may be leaked 🫣.
6.1. YANG Security Considerations 🔐
Okay bestie, this one is modeled after the template in Section 3.7 of [YANG-GUIDELINES], so it's giving very organized 💅. The "ietf-bfd-large" YANG module is built to be accessed through YANG-based management protocols like NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols have to use a secure transport layer (think SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and have to use mutual authentication 🫶.
The Network Configuration Access Control Model (NACM) [RFC8341] is the bouncer 🚪. It lets you restrict particular NETCONF or RESTCONF users to a preconfigured subset of protocol operations and content, so not everyone gets backstage access.
⚠️ Serious moment: there is exactly one data node in this module that is writable, creatable, and deletable (that's "config true", which is the default). All writable data nodes are likely to be pretty sensitive or vulnerable in some network environments. Write operations (like edit-config) and delete operations on these nodes without proper protection or authentication can have a negative effect on network operations 😭. This node has its own particular sensitivities and vulnerabilities:
pdu-sizeis the targeted size of BFD control packets encapsulated according to this proposal. Changing this value for a session in the Up state may cause the session to go down, possibly on purpose, if the session can't accommodate those BFD control packets 💀. Operators should be mindful that multiple BFD clients may rely on the status of a given BFD session when they change this value 🙈.
There are no particularly sensitive readable data nodes, and no particularly sensitive RPC or action operations. Lowkey a relief 🌸.
Modules that use the groupings defined in this document should identify the corresponding security considerations. For example, reusing some of these groupings will expose privacy-related information (like 'node-example') 👀. This module defines one such grouping, "bfd-large-common", which contains the pdu-size data node. Its security considerations are documented above, so go reread them 📖.
7. IANA Considerations 🦋
7.1. The "IETF XML" Registry
IANA has registered the following URI in the "ns" subregistry of the "IETF XML Registry" [RFC3688] ✨.
URI: urn:ietf:params:xml:ns:yang:ietf-bfd-large
Registrant Contact: The IESG
XML: N/A; the requested URI is an XML namespace.7.2. The "YANG Module Names" Registry
IANA has also registered the following YANG module in the "YANG Module Names" registry [RFC6020] 🍓.
Name: ietf-bfd-large
Maintained by IANA: N
Namespace: urn:ietf:params:xml:ns:yang:ietf-bfd-large
Prefix: bfdl
Reference: RFC 97648. References 📚
8.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[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/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
DOI 10.17487/RFC5881, June 2010,
<https://www.rfc-editor.org/info/rfc5881>.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
June 2010, <https://www.rfc-editor.org/info/rfc5883>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed.,
Binderberger, M., Ed., and J. Haas, Ed., "Bidirectional
Forwarding Detection (BFD) on Link Aggregation Group (LAG)
Interfaces", RFC 7130, DOI 10.17487/RFC7130, February
2014, <https://www.rfc-editor.org/info/rfc7130>.
[RFC7880] Pignataro, C., Ward, D., Akiya, N., Bhatia, M., and S.
Pallagatti, "Seamless Bidirectional Forwarding Detection
(S-BFD)", RFC 7880, DOI 10.17487/RFC7880, July 2016,
<https://www.rfc-editor.org/info/rfc7880>.
[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/info/rfc8174>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
[RFC9314] Jethanandani, M., Ed., Rahman, R., Ed., Zheng, L., Ed.,
Pallagatti, S., and G. Mirsky, "YANG Data Model for
Bidirectional Forwarding Detection (BFD)", RFC 9314,
DOI 10.17487/RFC9314, September 2022,
<https://www.rfc-editor.org/info/rfc9314>.8.2. Informative References
[BFD-ECHO-PATH-MTU]
Min, X., Ed. and J. Haas, Ed., "Application of the BFD
Echo function for Path MTU Verification or Detection",
Work in Progress, Internet-Draft, draft-haas-xiao-bfd-
echo-path-mtu-01, 11 July 2011,
<https://datatracker.ietf.org/doc/html/draft-haas-xiao-
bfd-echo-path-mtu-01>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
January 2006, <https://www.rfc-editor.org/info/rfc4252>.
[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/info/rfc6241>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[YANG-GUIDELINES]
Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines
for Authors and Reviewers of Documents Containing YANG
Data Models", Work in Progress, Internet-Draft, draft-
ietf-netmod-rfc8407bis-22, 14 January 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
rfc8407bis-22>.Acknowledgments 💖
The authors would like to thank Les Ginsberg, Mahesh Jethanandani, Robert Raszuk, and Ketan Talaulikar for their valuable feedback on this proposal 🫶✨. Iconic group of people, honestly.
Authors' Addresses 🌈
Jeffrey Haas
Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: jhaas@juniper.net
Albert Fu
Bloomberg L.P.
731 Lexington Avenue
New York, NY 10022
United States of America
Email: afu14@bloomberg.net📦 where this page comes from
- ietf: rfc9764 2025-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms