RFC 9940
Some Key Terms for Network Fault and Problem Management
RFC 9940: Some Key Terms for Network Fault and Problem Management 🎀
bestie, this one is RFC 9940 🧚 It's an Informational doc (so not a Standards Track spec 💅), published in April 2026 and marked with ISSN 2070-1721. The editors are N. Davis from Ciena and A. Farrel from Old Dog Consulting, and they're joined by T. Graf (Swisscom), Q. Wu (Huawei), and C. Yu (Huawei). The title block doesn't list anything it obsoletes or updates, so there's nothing to cross-check there 🌸
Abstract 💖
okay so this doc lays out some terms that are basically the foundation for everyone agreeing on what network fault and problem management means inside the IETF ✨ no cap, shared vocab is everything.
The whole point is to bring clarity to discussions and other work about network fault and problem management 🫶 The main audience is YANG data models and management protocols that report, make visible, or manage network faults and problems. It's giving organized and super useful 💅
Status of This Memo 🦋
This document is not an Internet Standards Track specification. It's published for informational purposes, so it's not trying to be a rule book 🌈
It's still a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 👑 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). ngl, not every IESG-approved doc is a candidate for any level of Internet Standard, and you can read Section 2 of RFC 7841 to see how that works 🙈
For the current status, errata, and a place to send feedback, check https://www.rfc-editor.org/info/rfc9940 💜
Copyright Notice 🌸
Copyright (c) 2026 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) as they stand on the date of publication. Please actually read those carefully, because they describe your rights and restrictions for 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 they come without warranty as described in the Revised BSD License. (bestie, that's the fine print, and it matters 😭)
Table of Contents 🧾
1. Introduction
2. Usage of Terms
3. Terminology
3.1. Context Terminology
3.2. Core Terms
3.3. Other Terms
4. Workflow Explanations
5. Security Considerations
6. Privacy Considerations
7. IANA Considerations
8. Informative References
Acknowledgments
Authors' Addresses1. Introduction 🧚
okay so successful operation of large networks depends on effective network management 💅 It needs a virtuous circle: network control, network observability, network analytics, network assurance, and then back to network control again 🔁 Network fault and problem management [RFC6632] is a big piece of that network management and control picture. It handles detecting, reporting, inspecting, isolating, correlating, and managing events inside the network 👀
This doc focuses on events that hurt the network's ability to forward traffic in line with expected behaviors, because that can shrink what the network can deliver as services 😬 Those events can also affect the ability to control and operate the network. The doc also covers other faults that lower the quality or reliability of the service you're getting. And the idea of fault and problem management stretches to cover the steps taken to find the causes of problems and to work toward getting expected network behavior back 🌈
A bunch of IETF work is building pieces of a fault management system, like YANG data models or management protocols ✨ So it really matters that everyone uses a common terminology. Otherwise nobody can tell how the parts of the management and control solutions fit together, or how faults and problems get handled 🫶
This doc sets out some terms that are fundamental to a common understanding of network fault and problem management. "Faults" and "problems" are concepts that apply at every level of technology on the Internet, but this doc is limited to the network layer and below. That's why it's specifically about "network fault and problem management." It also touches on "incidents," where an incident results from one or more problems and is the disruption of a network service 💥
Some useful terms are already defined in [RFC3877] and [RFC8632]. The definitions here are informed by those docs, but they don't depend on that earlier work 🦋
2. Usage of Terms 💅
The terms defined here are meant for consistent use within the IETF in the scope of network fault and problem management ✨ Where similar concepts show up in other bodies, the authors tried to harmonize with those descriptions. Still, care is needed where terms aren't used consistently between bodies, or where terms get applied outside the network layer 👀 If other bodies find this terminology useful, they're free to use it 🌸
The main purpose of this doc is to define the following terms for use in other documents. Other terms are defined to support those definitions too. They may also be used by other documents, though that's not their main job here 🧚
- Event
- State
- Fault
- Problem
- Symptom
- Cause
- Alert
- Alarm
When other documents use these terms as defined here, it's suggested that they capitalize the terms the way this document does. That helps tell them apart from colloquial uses 💖 Those documents should also include an early section that lists the terms inherited from this doc, with a citation 📚
3. Terminology 🎀
This section has the key terms, split into three subsections:
- Section 3.1 has terms that set the context for network fault and problem management systems.
- Section 3.2 has specific, detailed core terms that other documents will use when they describe elements of those systems.
- Section 3.3 gives three more terms that might be helpful.
3.1. Context Terminology 🌈
This section has some terminology that helps describe the context for the rest of the work 🫶 The terms can be seen as a cascaded sequence of processes, starting with Network Telemetry and building up to Network Observability. The definitions are deliberately kept fairly terse 🙈 Further documents may expand on these terms without losing specificity. Any contextualization like that should be clearly highlighted in those documents.
Network Telemetry: This is defined in [RFC9232]. It's the process of collecting operational network data, sorted by the network plane it came from (for example, Layer 3, Layer 2, and Layer 1) ✨ Data collected through Network Telemetry doesn't contain any data about service definitions (that's "intent" per Section 3.1 of [RFC9315]).
Network Monitoring: This is the process of keeping a continuous record of functions related to a network topology 📊 It involves tracking things like traffic patterns, device health, performance metrics, and overall network behavior. This is what makes Network Monitoring different from resource or device monitoring, which focuses on individual resources or components (Section 3.2) 💜
Network Analytics: This is the process of deriving analytical insights from operational network data 🧠 The process could be run by a piece of software, a system, or a human. It analyzes operational data and outputs new analytical data related to that operational data, like a symptom 🔥
Network Observability: This is the process of enabling network behavioral assessment by analyzing observed operational network data (logs, alarms, traces, etc.), with the aim of detecting symptoms of network behavior and identifying anomalies and their causes 🔍 Network Observability starts with information gathered using Network Monitoring tools, and that information may be further enriched with other operational data 🦋 The expected outcome is identifying and analyzing deviations between observed state and the expected state of a network 💅
So there's a cascaded sequence with these relationships:
- Network Telemetry is the process of collecting operational data from a network ✨
- Network Monitoring is the process of creating and keeping a record of data gathered in Network Telemetry 📝
- Network Analytics is the process of deriving insight from the data recorded in Network Monitoring 🧚
- Network Observability is the process of enabling behavioral assessment of a network through Network Analytics 🌸
3.2. Core Terms ✨
okay so these terms are lined up to flow top to bottom, so you can build understanding as you go 🧠 Section 4 has figures and explanations that can help too 📊 bestie, let's go 💅
Resource: A Resource is an element of a network system. 🌸
- Resource is a recursive concept, so a Resource may be a collection of other Resources. For example, a network node is a collection of network interfaces 🧚
Characteristic: A Characteristic is an observable or measurable aspect or behavior associated with a Resource. 👀
- A Characteristic may be considered to be built on facts (see "Value", below) and the contexts and descriptors that identify and give meaning to the facts. It's giving layers 🎀
- The term "Metric" (see "metric" in [RFC9417]) is another word for a measurable Characteristic, which may also be thought of as analogous to a "variable". 📏
Value: A Value is a measure of a Characteristic associated with a Resource. It may be in the form of a categorization (e.g., high or low), an integer (e.g., a count or gauge), or a reading of a continuous variable (e.g., an analog measurement), etc. 💜
Change: In the context of Network Monitoring, a Change is the variation in the Value of a Characteristic associated with a Resource. A Change may arise over a period of time. ⏳
- Not all Changes are noteworthy (i.e., they do not have Relevance). 🙈
- Perception of Change depends upon Detection, the sampling rate/accuracy/detail, and perspective. 🔍
- It may be helpful to qualify this as "Value Change" because the English word "change" is often heavily used. 💅
Event: An Event is the variation in Value of a Characteristic of a Resource at a distinct moment in time (i.e., the period is negligible). ⚡
- Compared with a Change, which may be over a period of time, an Event happens at a distinct moment in time. Thus, an Event may be the observation of a Change. 📸
Condition: A Condition is an interpretation of the Values of a set of one or more Characteristics of a Resource (with respect to working order or some other aspect relevant to the Resource purpose/application) -- for example, "low available memory". Thus, it is the output of a function applied to a set of one or more variables. 🧮
State: A State is a particular Condition that a Resource has (i.e., it is in a State) at a specific time. For example, a router may report the total amount of memory it has and how much is free. These are the Values of two Characteristics of a Resource. These Values can be interpreted to determine the Condition of the Resource, and that may determine the State of the router, such as shortage of memory. 🖥️✨
- While a State may be observed at a specific moment in time, it is actually determined by summarizing measurement over time in a process sometimes called State compression. 🗜️
- It may be helpful to qualify this as "Resource State" to make clear the distinction between this and other uses of "state" such as "protocol state". 🏷️
- This term may be contrasted with "operational state" as used in [RFC8342]. For example, the state of a link might be up/down/degraded, but the operational state of the link would include a collection of Values of Characteristics of the link. 🔗
Detect (hence Detected, Detection): To Detect is to notice the presence of something (State, Change, Event, activity, etc.) 🕵️♀️
- Also to notice a Change (from the perspective of an observer such as a monitoring system). 👁️
Relevance: Relevance is the consideration of an Event, State, or Value (through the application of policy, relative to a specific perspective or intent, and in relation to other Events, States, and Values) to determine whether it is of note to the system that controls or manages the network. Note, for example, that not all Changes are Relevant. 🎯
- This term may also be used as "Relevant Event", "Relevant State", or "Relevant Value". 🫶
Occurrence: An Occurrence is a Relevant Event or a particular Relevant Change. 🌟
- An Occurrence may be an aggregation or abstraction of multiple fine-grained Events or Changes. 🧩
- An Occurrence may occur at any macro or micro scale because Resources are a recursive concept. An Occurrence may be perceived, depending on the scope of observation (i.e., according to the level of Resource recursion that is examined). That is, Occurrences, themselves, are a recursive concept. 🪆
Fault: A Fault is an Occurrence (i.e., an Event or a Change) that is not desired/required (as it may be indicative of a current or future undesired State). Thus, a Fault happens at a moment in time. A Fault can potentially be associated with a Cause. See [RFC8632] for a more detailed discussion of network faults. 🚨
- Note that there is a distinction between a Fault and a Problem that depends on context. For example, in a connectivity service where redundancy is present, a link down is a Problem, but from the perspective of managing the network resources, a link down is a Fault. Likewise, for example, in a router with two power supplies, if the backup power supply fails leaving the primary unprotected, this is a Problem. 🔌
Problem: A Problem is a State that is undesirable and that may require remedial action. A Problem cannot necessarily be associated with a Cause. The resolution of a Problem does not necessarily act on the thing that has the Problem. 😤
- Note that there is a historic aspect to the concept of a Problem. The current State may be operational, but there could have been a Fault that is unexplained, and the fact of that unexplained recent Fault is a Problem. 🕰️
- Note that while a Problem is unresolved it may continue to require attention. A record of resolved Problems may be maintained in a log. 📒
- Note that there may be a State that is considered to be a Problem from several perspectives. For example, consider a "loss of light" State that may cause multiple services to fail. In this example, a new State (the light recovers) may cause the Problem to be resolved from one perspective (the services are operational once more) but may leave the Problem as unresolved (because the loss of light has not been explained). Further, in this example, there could be another development (the reason for the temporary loss of light is traced to a microbend in the fiber that is repaired) resulting in that unresolved Problem now being resolved. But, in this example, this still leaves a further Problem unresolved (a microbend occurred, and that Problem is not resolved until it is understood how it occurred and a remedy is put in place to prevent recurrence). 💡🔦
Cause: A Cause is the Events (Detected or otherwise) that gave rise to a Fault/Problem. 🔎
Incident: Also referred to as "Network Incident". An Incident is an undesired Occurrence such as an unexpected interruption of a network service, degradation of the quality of a network service, or the below-target performance of a network service. An Incident results from one or more Problems, and a Problem may give rise to or contribute to one or more Incidents. Greater discussion of Network Incident relationships, including Customer Incidents and Incident management, can be found in [Net-Incident-Mgmt-YANG]. 🧨
Symptom: A Symptom is an observable Value, Change, State, Event, or Condition considered as an indication of a Problem or potential Problem. 🩺
Anomaly: Also referred to as "Network Anomaly". An Anomaly is an unusual or unexpected Event or pattern in network data in the forwarding plane, control plane, or management plane that deviates from the normal, expected behavior. See [Net-Anomaly-Arch] for more details. 🛸
Alert: An Alert is an indication of a Fault. 📣
Alarm: As specified in [RFC8632], an Alarm signifies an undesirable State in a Resource that requires corrective action. From a management point of view, an Alarm can be seen as a State in its own right and the transition to this State may result in an Alert being issued. The receipt of this Alert may give rise to a continuous indication (to a human operator) highlighting the potential or actual presence of a Problem. 🚩🔔
3.3. Other Terms 🌈
Three other terms may be helpful: 💖
Intermittent: A State that is not continuous but that keeps recurring in some time frame. 🔁
Transient: A State that is not continuous and that occurs once in some time frame. ⚡
Recurrent: A Problem that is actively resolved but returns. 🦋
4. Workflow Explanations ✨
okay bestie, this section is all about how the terms from Section 3.2 hang out together when we're dealing with network faults and problems 🕵️♀️💖 the text and figures are just here to explain things, they aren't the official definitions, so don't quote them as law 🙈
first up, Figure 1 🎀 a Network system has Resources, and Resources have Characteristics. the relationship is one-to-many (1:n) both times, but the figure doesn't show that, so picture the many branches yourself 🌸
Characteristics
^
|
Resources
^
|
Network system
Figure 1: Resources and Characteristicsthe Value of a Characteristic can totally change over time 🦋 some changes happen at one specific moment (digital Changes). those get Detected and become Events. that's the left side of Figure 2 ✨
the middle of Figure 2 is the Value changing over time, too. it can be Detected at certain times or periodically, and those Values can turn into Conditions, which are States (so State Changes happen as a result) 💅
then there's the analog vibe 🌈 the Characteristic can vary smoothly over time, like on the right side of Figure 2. you can read or report it periodically (that's Detecting), and those readings can become Relevant Values. or it can get evaluated over time, which is shown in Figure 6 🫶
Event State Value
Condition
^ ^ ^
Detect : Detect : Detect :
: : :
^ ^ ^ ^ ^ /\
: : : : : / \
: : : : : /\ / \
__ __ _____ / \/
| | | | /\/
__| |__ ____| |____ /
Change at a time Change over time Change over time
Figure 2: Characteristics and Changesnow the Events workflow 🔥 Figure 3 is all about how an Event grows up. an Event is just a Change in a Characteristic's Value at a time. then it gets evaluated (with policy, from a specific perspective, with intent in mind, and alongside other Events, States, and Values) to figure out if it's an Occurrence and maybe trigger a Change of State 👑
an Occurrence can be undesirable, which makes it a Fault, and a Fault might generate an Alert 🚨 or an Occurrence can be evidence of a Problem, and it could directly point to a Cause 💀 sometimes an Alert escalates into an Alarm, which is a flag for a potential or actual Problem 😭
Alert - - - > Alarm
^
|
| -----> Cause
| |
|----------> Problem
|
|
Fault
^
|
|
|
Occurrence
^
|
|----------> State
|
|
Event
Figure 3: Event and Dependent Termsthe States workflow runs parallel to that 💜 Figure 4 shows it. like Figure 2 said, a Change noticed at a particular time gives rise to a State. that State can be deemed to have Relevance, based on policy, perspective, intent, and its relationship to other Events, States, and Values ✨ a Relevant State might be a Problem, or it might indicate a Problem or a potential one 🧚
Problems can be looked at through their Symptoms and can map directly or indirectly to Causes 🔍 one or more Problems result in an Incident 💥 an Alarm can be raised because of a Problem, and moving into an alarmed State can trigger an Alert 🔔
Alarm - - -> Alert
^
| ------> Incident
| |
| | ---> Cause
| | |
Problem---------> Symptom
^
|
| Relevance
|
|
State
Figure 4: State and Dependent TermsFigure 5 is the consolidation moment 🧩 it shows how Faults and Problems come together to figure out the Causes. the arrows show how one thing gives rise to another ➡️
a Cause can be indicated by, or determined from, Faults, Problems, and Symptoms 💖 one Cause can point to another, and a Cause can also be treated as a Symptom 🪞 figuring out Causes can take multiple inputs into account, and one or more Problems still result in an Incident 🍓
---------
------------- | |
| ----------> | Symptom |
| | | |
| | ---------
v | ^
--------- |
------->| Cause |<--------- |
| --------- | |
| ^ | | |
| | | | |
| --- | |
| | |
--------- --------- ----------
| Fault |------------------->| Problem |------->| Incident |
--------- --------- ----------
Figure 5: Consolidation of Symptoms and CausesFigure 6 is where thresholds come in 🌸 they matter a lot when you're looking at analog Values and Events. the arrows show how one thing may give rise to, or use, another. threshold-driven Events and States (and the Alerts they might trigger) need to be handled with care 🙈 you want to dampen any "flapping" so consistent States can actually be observed, and you don't want to overwhelm the management processes or systems 😭
analog Values can be read or notified from the Resource, and they could cross a threshold, be deemed Relevant Values, or be evaluated over time 📈 Events can be counted, and that Count might cross a threshold or hit a Relevant Value 🧮
the Threshold Process can be implementation specific and subject to policies 🎀 when a threshold gets crossed and any other conditions match up, an Event can be determined and then handled like any other Event 💅
Occurrence
^
|
|---------------------> State
|
| ------- Relevance
|------>| Count |-----------------------------> Value
| ------- | ^
| | | |
| | | | Relevance
| | v |
| | ----------- ----------------
Event | | Evaluated | | |
^ | | over time |<--------| Analog Value |
| v ----------- | |
| ----------- | | |
| | Threshold | | | |
|<----| Process |<------ | |
| | |<----------------------| |
| ----------- ----------------
| ^
| |
| Detect Detect |
| |
Change at a Time Change over Time
Figure 6: Counts, Thresholds, and Values5. Security Considerations 🔐
this document is all about terminology, so it doesn't have any direct effect on the security of implementations or deployments 🫶 BUT protocol solutions and management models still need to be aware of a few things, so listen up 👀
- exposing info about Faults and Problems can reveal how a network works on the inside (especially its vulnerabilities) 😱 and an attacker would love that intel 💀
- systems that generate management info (messages, notifications, etc.) when Faults happen can get attacked by making them produce so much info that the system managing the network gets swamped and can't manage the network properly 🌪️ literally a nightmare
- reporting false info about Faults (or hiding reports of Faults) can make the system managing the network function incorrectly 🙅♀️ not it, not cute, do not do this
6. Privacy Considerations 🌷
network fault and problem management should protect user privacy by not exposing user data or info about end-user activities 🫧
network Telemetry involves observing network traffic and collecting operational data from the network, while network Monitoring is the process of keeping records of the data gathered in Network Telemetry 📼 so the data being observed and collected might include users' privacy info 😳 that info must be protected and controlled so it doesn't get exposed to unauthorized parties 🔒 extra care may be needed for stored info that could be accessed at any time, even far into the future ⏳
also, a network operator will be worried about keeping control of all info about Faults, to protect their own privacy and the details of how they run their network 🕶️✨
7. IANA Considerations 🧁
this document has no IANA actions 💜
- Informative References
[Net-Anomaly-Arch] ...
Wait, I need to be careful here. Let me get the text right.
Actually, I should stop and think about what's going on. The user asked for the rewrite of part 4 of RFC 9940. The system prompt instructs me to rewrite the RFC in a Gen Z voice while keeping every detail. The rest of the context (environment, model info, user email) is just setup. Nothing there asks me to do anything odd. So the task is fine; I just need to produce the rewritten part 4.
Let me write it out. Section 8 heading as "# 8. Informative References ✨". Then the references, in a code block? References are text, not grammar, so plain paragraphs are okay, but the reference entries should keep all details. Reference tags and URIs should be exact; I'll put URIs in backticks. The references list is tricky: it's a list of entries with tags like [RFC3877]. Keep the tags exact, in backticks maybe. Keep titles in quotes, DOIs, dates, URLs exact.
Acknowledgments and Authors' Addresses: keep all names and addresses. Addresses are multiline; put in a fenced block to keep exact? Addresses are not code, but preserving line structure is cleaner in a code block. I'll use a fenced block for the author addresses to keep them exact. The system says code blocks for grammars etc.; addresses in a block is fine.
Also "Special thanks" list: bullets.
Keep the title block facts; they're in earlier parts already. Fine.
No BCP 14 key words here. Careful not to write "must" in caps. Fine.
Write voice with emoji and colour tags, no links (URLs in backticks are fine as inline code, since links aren't allowed as markdown links).# 8. Informative References ✨
Okay bestie, this is the reading list 📚 Every doc here is a "go read this if you want the full story" kind of source, and I'm listing each one with all its details so nobody gets lost.
[Net-Anomaly-Arch]: Graf, T., Du, W., Francois, P., and A. Huang Feng, "A Framework for a Network Anomaly Detection Architecture", Work in Progress, Internet-Draft, draft-ietf-nmop-network-anomaly-architecture-06, 21 November 2025,https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-anomaly-architecture-06.[Net-Incident-Mgmt-YANG]: Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng, "A YANG Data Model for Network Incident Management", Work in Progress, Internet-Draft, draft-ietf-nmop-network-incident-yang-08, 13 February 2026,https://datatracker.ietf.org/doc/html/draft-ietf-nmop-network-incident-yang-08.[RFC3877]: Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877, September 2004,https://www.rfc-editor.org/info/rfc3877. 🎀[RFC6632]: Ersue, M., Ed. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, DOI 10.17487/RFC6632, June 2012,https://www.rfc-editor.org/info/rfc6632. 🌸[RFC8342]: Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,https://www.rfc-editor.org/info/rfc8342. 💜[RFC8632]: Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm Management", RFC 8632, DOI 10.17487/RFC8632, September 2019,https://www.rfc-editor.org/info/rfc8632. 🦋[RFC9232]: Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and A. Wang, "Network Telemetry Framework", RFC 9232, DOI 10.17487/RFC9232, May 2022,https://www.rfc-editor.org/info/rfc9232. ⭐[RFC9315]: Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", RFC 9315, DOI 10.17487/RFC9315, October 2022,https://www.rfc-editor.org/info/rfc9315. 🧚[RFC9417]: Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T. Arumugam, "Service Assurance for Intent-Based Networking Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023,https://www.rfc-editor.org/info/rfc9417. 👑
Acknowledgments 🫶
The authors would like to thank Med Boucadair, Wanting Du, Joe Clarke, Javier Antich, Benoit Claise, Christopher Janz, Sherif Mostafa, Kristian Larsson, Dirk Von Hugo, Carsten Bormann, Hilarie Orman, Stewart Bryant, Bo Wu, Paul Kyzivat, Jouni Korhonen, Reshad Rahman, Rob Wilton, Mahesh Jethanandani, Tim Bray, Paul Aitken, and Deb Cooley for their helpful comments. Literal thank-you-for-the-feedback energy, and they deserve it 💖
Special thanks to the team that met at a side meeting at IETF 120 to discuss some of the thorny issues:
- Benoit Claise
- Watson Ladd
- Brad Peters
- Bo Wu
- Georgios Karagiannis
- Olga Havel
- Vincenzo Riccobene
- Yi Lin
- Jie Dong
- Aihua Guo
- Thomas Graf
- Qin Wu
- Chaode Yu
- Adrian Farrel
Authors' Addresses 📮
Nigel Davis (editor)
Ciena
United Kingdom
Email: ndavis@ciena.com
Adrian Farrel (editor)
Old Dog Consulting
United Kingdom
Email: adrian@olddog.co.uk
Thomas Graf
Swisscom
Binzring 17
CH-8045 Zurich
Switzerland
Email: thomas.graf@swisscom.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing
Jiangsu, 210012
China
Email: bill.wu@huawei.com
Chaode Yu
Huawei
Email: yuchaode@huawei.comThat's the whole doc, bestie! 🌈✨ Thanks to everyone who made it happen 💅
📦 where this page comes from
- ietf: rfc9940 2026-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms