<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!-- pre-edited by ST 09/04/25 --> <!-- pre-edited by ST 09/11/25 --> <!-- reference review by TH 10/07/25 --> <!DOCTYPE rfc [ <!ENTITYRFC3877 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3877.xml"> <!ENTITY RFC6632 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6632.xml"> <!ENTITY RFC8342 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8342.xml"> <!ENTITY RFC8632 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8632.xml"> <!ENTITY RFC9232 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9232.xml"> <!ENTITY RFC9315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9315.xml">nbsp " "> <!ENTITYRFC9417 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9417.xml">zwsp "​"> <!ENTITYI-D.ietf-nmop-network-anomaly-architecture SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-nmop-network-anomaly-architecture">nbhy "‑"> <!ENTITYI-D.ietf-nmop-network-incident-yang SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-nmop-network-incident-yang">wj "⁠"> ]><?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-nmop-terminology-23" number="9940" consensus="true" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="Network Fault Terminology">Some Key Terms for Network Fault and Problem Management</title> <seriesInfoname="Internet-Draft" value="draft-ietf-nmop-terminology-23"/>name="RFC" value="9940"/> <author initials="N." surname="Davis" fullname="Nigel Davis" role="editor"> <organization>Ciena</organization> <address> <postal><street/> <city/><country>United Kingdom</country> </postal> <email>ndavis@ciena.com</email> </address> </author> <author initials="A." surname="Farrel" fullname="Adrian Farrel" role="editor"> <organization>Old Dog Consulting</organization> <address> <postal><street/> <city/><country>United Kingdom</country> </postal> <email>adrian@olddog.co.uk</email> </address> </author> <author fullname="Thomas Graf" initials="T" surname="Graf"> <organization>Swisscom</organization> <address> <postal> <street>Binzring 17</street> <city>Zurich</city> <code>8045</code> <country>Switzerland</country> </postal> <email>thomas.graf@swisscom.com</email> </address> </author> <author fullname="Qin Wu" initials="Q." surname="Wu"> <organization>Huawei</organization> <address> <postal> <street>101 Software Avenue, Yuhua District</street> <city>Nanjing</city> <region>Jiangsu</region> <code>210012</code> <country>China</country> </postal> <email>bill.wu@huawei.com</email> </address> </author> <author initials="C." surname="Yu" fullname="Chaode Yu"> <organization>Huawei Technologies</organization> <address> <email>yuchaode@huawei.com</email> </address> </author> <!-- [rfced] Authors' Addresses: We see that Qin Wu's affiliation is listed as Huawei in this document. Please confirm that this is as desired. We ask because we see that Qin Wu's affiliation is mostly listed as Huawei after RFC 9000, but as "Huawei Technologies" in RFCs 9005, 9353, 9358, and 9731. --> <dateyear="2025"/>year="2026" month="February"/> <area>OPS</area> <workgroup>nmop</workgroup> <keyword>Problem</keyword> <keyword>Event</keyword> <keyword>Fault</keyword> <keyword>Occurrence</keyword> <keyword>Incident</keyword><keyword>Anomally</keyword><keyword>Anomaly</keyword> <keyword>Symptom</keyword> <keyword>Alert</keyword> <keyword>Alarm</keyword> <abstract> <t>This document sets out some terms that are fundamental to a common understanding of network fault and problem management within the IETF.</t> <t>The purpose of this document is to bring clarity to discussions and other work related to network fault and problemmanagement,management -- inparticularparticular, to YANG data models and management protocols that report, make visible, or manage network faults and problems.</t> </abstract> </front> <middle> <section anchor="introduction" numbered="true" toc="default"> <name>Introduction</name> <t>Successful operation of large networks depends on effective network management. This requires a virtuous circle of network control, network observability, network analytics, network assurance, and back to network control. Network fault and problem management <xref target="RFC6632" /> is an important aspect of network management and control solutions. It deals with the detection, reporting, inspection, isolation, correlation, and management of events within the network. The intention of this document is to focus on those events that have a negative effect on thenetwork'snetwork's ability to forward traffic according to expected behavior and so deliver services, the ability to control and operate the network, and other faults that reduce the quality or reliability of the delivered service. The concept of fault and problem management extends to include actions taken to determine the causes of problems and to work toward recovery of expected networkbehavior.</t>behavior. <!-- [rfced] Section 1: Please clarify the meaning of this sentence, especially how the phrase "and other faults" relates to the rest of the sentence. Original: The intention of this document is to focus on those events that have a negative effect on the network's ability to forward traffic according to expected behavior and so deliver services, the ability to control and operate the network, and other faults that reduce the quality or reliability of the delivered service. Option A: The intention of this document is to focus on those events that could have a negative effect on the network's ability to forward traffic according to expected behavior and so could negatively affect delivery of services and the ability to control and operate the network. Such events could also trigger other faults that would reduce the quality or reliability of the delivered service. Option B: The intention of this document is to focus on those events that have a negative effect on the network's ability to forward traffic according to expected behavior and thus its ability to deliver services, provide the ability to control and operate the network, and manage faults that would reduce the quality or reliability of the delivered service. Option C: This document focuses on events that have a negative effect on traffic forwarding, service delivery, and network management, especially when managing faults that reduce the quality or reliability of the delivered service. --> </t> <t>A number of work efforts within the IETF seek to provide components of a fault management system, such as YANG data models or management protocols. It is important that a common terminologyisbe used so that there is a clear understanding of how the elements of the management and control solutions fittogether,together and how faults and problems will be handled.</t> <t>This document sets out some terms that are fundamental to a common understanding of network fault and problem management. While "faults" and "problems" are concepts that apply at all levels of technology in the Internet, the scope of this document is restricted to the network layer andbelow, hencebelow; hence, this document is specifically about "network fault and problemmanagement."management". The concept of "incidents" is also touched on in this document, where an incident results from one or more problems and is the disruption of a network service.</t> <t>Note that some useful terms are defined in <xref target="RFC3877" /> and <xref target="RFC8632" />. The definitions in this document are informed by those documents, but they are not dependent on that prior work.</t> </section> <section anchor="usage" numbered="true" toc="default"> <name>Usage of Terms</name> <t>The terms defined in this document are intended for consistent use within the IETF in the scope of network fault and problem management. Where similar concepts are described in other bodies, an attempt has been made to harmonize with those other descriptions, butthere iscare is needed where terms are not used consistently between bodies or where terms are applied outside the network layer. If other bodies find the terminology defined in this document useful, they are free to use it.</t> <t>The purpose of this document is to define the following terms for use in other documents. Other terms are defined to enable those definitions and may also be used by other documents, although that is not the principal purpose of their definitions here.</t> <ul spacing="compact"> <li>Event</li> <li>State</li> <li>Fault</li> <li>Problem</li> <li>Symptom</li> <li>Cause</li> <li>Alert</li> <li>Alarm</li> </ul> <t>When other documents make use of the terms as defined in this document, it is suggested here that such uses should use capitalization of the terms as done in this document to help distinguish them from colloquialuses,uses and should include an early section listing the terms inherited from this document with a citation.</t> </section> <section anchor="terms" numbered="true" toc="default"> <name>Terminology</name> <t>This section contains key terms. It is split into three subsections.</t> <ul> <li> <t><xref target="context" /> contains terms that helptoset the context for network fault and problem management systems.</t> </li> <li> <t><xref target="core" /> includes specific and detailed core terms that will be used in other documents that describe elements of the network fault and problem management systems.</t> </li> <li> <t><xref target="other" /> provides three further terms that may be helpful.</t> </li> </ul> <section anchor="context" numbered="true" toc="default"> <name>Context Terminology</name> <t>This section includes some terminology that helps describe the context for the rest of this work. The terms may be viewed as a cascaded sequence of processes, starting with Network Telemetry and building to Network Observability. The definitions are deliberately kept relatively terse. Further documents may expand on these terms without loss of specificity. Such contextualization (if any) should be highlighted clearly in those documents.</t> <dl newline="false" spacing="normal"> <dt>Network Telemetry:</dt> <dd><t>This is defined in <xref target="RFC9232" /> and describes the process of collecting operational network data categorized according to the network plane (e.g., Layer 3, Layer 2, and Layer 1) from which it was derived. Data collected through the Network Telemetry process does not contain any data related to service definitions (i.e., "intent" per <xref target="RFC9315" section="3.1"/>).</t> <!-- [rfced] Section 3.1: a) FYI, we capitalized "layer 3, layer 2, and layer 1" to "Layer 3, Layer 2, and Layer 1", per more common usage in RFCs after RFC 6000. b) Is "intent" the only type of service definition (in which case "i.e.," ("that is") is correct), or should "i.e.," be "e.g.," ("for example")? Original: Network Telemetry: This is defined in [RFC9232] and describes the process of collecting operational network data categorized according to the network plane (e.g., layer 3, layer 2, and layer 1) from which it was derived. Data collected through the Network Telemetry process does not contain any data related to service definitions (i.e., "intent" per Section 3.1 of<xref target="RFC9315" />).</t></dd>[RFC9315]). --> </dd> <dt>Network Monitoring:</dt> <dd><t>This is the process of keeping a continuous record of functions related to a network topology. It involves tracking various aspects such as traffic patterns, device health, performance metrics, and overall network behavior. This approach differentiates network monitoring from resource or device monitoring, which focuses on individual resources or components (<xref target="core"/>).</t> <!-- [rfced] Section 3.1: Should "network monitoring" be "Network Monitoring" in this paragraph, to match other comparable terms mentioned in Sections 2 and subsequent? Also, we see "through the Network Telemetry process" in the previous paragraph (i.e., initial capitals applied again after the term has been defined). Original: Network Monitoring: This is the process of keeping a continuous record of functions related to a network topology. It involves tracking various aspects such as traffic patterns, device health, performance metrics, and overall network behaviour. This approach differentiates network monitoring from resource or device monitoring, which focuses on individual components or resources(<xref target="core"/>).</t></dd>(Section 3.2). --> </dd> <dt>Network Analytics:</dt> <dd><t>This is the process of deriving analytical insights from operational network data. A process could be executed by a piece of software, a system, or a human that analyzes operational data and outputs new analytical data related to the operationaldata,data -- for example, a symptom.</t></dd> <dt>Network Observability:</dt> <dd><t>This is the process of enabling network behavioral assessment through analysis of observed operational network data (logs, alarms, traces, etc.) with the aim of detecting symptoms of network behavior, and to identify anomalies and their causes. Network Observability begins with information gathered using Network Monitoring tools and that may be further enriched with other operational data. The expected outcome of the observability processes is identification and analysis of deviations in observed state versus the expected state of anetwork.</t></dd>network.</t> <!-- [rfced] Section 3.1: a) Does "and to identify" refer to the Network Observability process or the analysis of the data? Original: Network Observability: This is the process of enabling network behavioral assessment through analysis of observed operational network data (logs, alarms, traces, etc.) with the aim of detecting symptoms of network behavior, and to identify anomalies and their causes. Perhaps (the process): Network Observability: This is the process of enabling network behavioral assessment through analysis of observed operational network data (logs, alarms, traces, etc.); this process aims to detect symptoms of network behavior and to identify anomalies and their causes. Or possibly: (the analysis): Network Observability: This is the process of enabling network behavioral assessment through analysis of observed operational network data (logs, alarms, traces, etc.); such analysis aims to detect symptoms of network behavior and to identify anomalies and their causes. b) May we update this sentence as follows to clarify "and that"? Original: Network Observability begins with information gathered using Network Monitoring tools and that may be further enriched with other operational data. Perhaps: Network Observability begins with information gathered using Network Monitoring tools, then it may be further enriched with other operational data. --> </dd> </dl> <t>Thus, there is a cascaded sequence where the following relationships apply:</t> <ul> <li>Network Telemetry is the process of collecting operational data from a network.</li> <li>Network Monitoring is the process of creating/keeping a record of data gathered in Network Telemetry.</li> <li>Network Analytics is the process of deriving insight through the data recorded in Network Monitoring.</li> <li>Network Observability is the process of enabling behavioral assessment of a network through Network Analytics.</li> </ul> </section> <section anchor="core" numbered="true" toc="default"> <name>Core Terms</name> <!-- [rfced] Section 3.2: To achieve parallelism in the list provided in this section, we made several updates to the definition paragraphs (the top-level items). For consistency of style, we went with sentence fragments instead of complete sentences. Please review, and let us know any objections. --> <t>The terms in this section are presentedbelowin an order that is intended to flow such that it is possible to gain understanding reading top to bottom. The figures and explanations in <xref target="explain" /> may aid understanding the terms set out here.</t> <dl newline="false" spacing="normal"> <dt>Resource:</dt> <dd><t>An element of a networksystem.</t>system. <!-- [rfced] Sections 3.2 and 4: We see one instance of "network system" in Section 3.2 but two instances of "Network system" in Section 4. Because this term isn't specifically defined anywhere, may we change the "between Network system and Resources" text in Section 4 to "between a network system and Resources", and may we change "Network system" in Figure 1 to "Network System"? Original: Resource: An element of a network system. ... Note that there is a 1:n relationship between Network system and Resources, and between Resources and Characteristics: this is not shown on the figure for clarity. ... Network system --> </t> <ul> <li> <t>Resource is a recursive concept so that a Resource may be a collection of other Resources (for example, a network node comprises a collection of networkinterfaces).</t></dd>interfaces).</t> </li> </ul> </dd> <!-- [rfced] Section 3.2: For consistency of style, we put "Resource is a recursive concept" under "Resource:" in a <ul>, as was done for the rest of the definitions in this section with nested paragraphs. Please let us know if you prefer otherwise. Original: Resource: An element of a network system. Resource is a recursive concept so that a Resource may be a collection of other Resources (for example, a network node comprises a collection of network interfaces). Currently: Resource: An element of a network system. * Resource is a recursive concept so that a Resource may be a collection of other Resources (for example, a network node comprises a collection of network interfaces). --> <dt>Characteristic:</dt> <dd><t>Observable or measurable aspect or behavior associated with a Resource.</t> <ul> <li> <t>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.</t> </li> <li> <t>The term "Metric" <xref target="RFC9417" /> is another word for a measurable Characteristic which may also be thought of as analogous to a'variable'.</t>'variable'. <!-- [rfced] Section 3.2: a) We see only two instances of single-quoted items in this document and see double quotes used for all other terms (e.g., "Value Change"). May we use double quotes instead for these two items, i.e., change 'Value' to "Value" and 'variable' to "variable" here? b) We see "metric" used in the text of RFC 9417, which uses "Metric" only in three definitions and its Figure 1. May we lowercase this term in this document to match RFC 9417, as it's only used as a term in this one bullet item? Original: * 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. * The term "Metric" [RFC9417] is another word for a measurable Characteristic which may also be thought of as analogous to a 'variable'. Perhaps: * 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. * The term "metric" [RFC9417] is another word for a measurable Characteristic, which may also be thought of as analogous to a "variable". --> </t> </li> </ul></dd> <dt>Value:</dt> <dd><t>AValue is ameasure 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.</t></dd>etc.</t> <!-- [rfced] Sections 3.2 and 4: We see "a count" in Section 3.2 but "the Count" in Section 4. Should capitalization of this term be made consistent? If yes, please specify which form is preferred. Original: 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. ... Events may be counted, and the Count may cross a threshold or reach a Relevant Value. --> </dd> <dt>Change:</dt> <dd><t>In the context of Network Monitoring,a Change isthe variation in the Value of a Characteristic associated with aResource andResource. A Change may arise over a period of time.</t> <ul> <li> <t>Not all Changes are noteworthy (i.e., they do not have Relevance).</t> </li> <li> <t>Perception of Change depends upon Detection, the sampling rate/accuracy/detail, and perspective.</t> </li> <li> <t>It may be helpful to qualify this as "Value Change" because the English word "change" is often heavily used.</t> </li> </ul> </dd> <dt>Event:</dt> <dd><t>The variation in Value of a Characteristic of a Resource at a distinct moment in time (i.e., the period isnegligible).</t>negligible). <!-- [rfced] Section 3.2: Is the period (of time) always negligible, or should "i.e.," be "e.g.," here? Original: Event: The variation in Value of a Characteristic of a Resource at a distinct moment in time (i.e., the period is negligible). --> </t> <ul> <li> <t>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.</t> </li> </ul> </dd> <dt>Condition:</dt><dd><t>A Condition is an<dd><t>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 Resourcepurpose/application),purpose/application) -- forexampleexample, "low available memory". Thus, it is the output of a function applied to a set of one or more variables.</t></dd> <dt>State:</dt> <dd><t>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 ithas,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.</t> <ul> <li> <t>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.</t> </li> <li> <t>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".</t> </li> <li> <t>This term may be contrasted with "Operational State" as used in <xref target="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. <!-- [rfced] Section 3.2: RFC 8342 uses the lowercase form "operational state". Because this sentence says "as used in [RFC8342]", would you prefer to follow usage in RFC 8342 or leave both "Operational State" and "operational state" as they are in this paragraph? Original: * 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 link would include a collection of Values of Characteristics of thelink.</t>link. --> </t> </li> </ul> </dd> <dt>Detect (hence Detected, Detection):</dt> <dd><t>To notice the presence of something (State, Change, Event, activity,etc.).</t> <ul> <li> <t>Henceetc.) and hence also to notice a Change (from the perspective of an observer such as a monitoring system).</t></li> </ul></dd> <dt>Relevance:</dt> <dd><t>Consideration of an Event, State, or Value (through the application of policy, relative to a specific perspective, 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 areRelevant.</t>Relevant. <!-- [rfced] Section 3.2: We had trouble following this sentence. Should "relative to a specific perspective, intent, ..." be "relative to a specific perspective, with a view to intent, ..." per text seen twice in Section 4? If not, what do "relative to a specific perspective" and "and in relation to other Events ..." refer to? Original: Relevance: Consideration of an Event, State, or Value (through the application of policy, relative to a specific perspective, 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. --> </t> <ul> <li> <t>This term may also be used as "Relevant Event", "Relevant State", or "Relevant Value".</t> </li> </ul> </dd> <dt>Occurrence:</dt> <dd><t>A Relevant Event or a particular Relevant Change.</t> <ul> <li> <t>An Occurrence may be an aggregation or abstraction of multiplefine-grainfine-grained Events orChanges.</t>Changes. </t> </li> <li> <t>An Occurrence may occur at any macro or micro scale because Resources are a recursive concept, and 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. <!-- [rfced] Section 3.2: Does "and may be perceived" refer to the Occurrence or the Resources in this sentence? If "Resources", we suggest inserting "they". Original: * An Occurrence may occur at any macro or micro scale because Resources are a recursive concept, and 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 recursiveconcept.</t>concept. --> </t> </li> </ul> </dd> <dt>Fault:</dt> <dd><t>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 <xref target="RFC8632" /> for a more detailed discussion of network faults.</t> <ul> <li> <t>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.</t> </li> </ul> </dd> <dt>Problem:</dt> <dd><t>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.</t> <ul> <li> <t>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.</t> </li> <li> <t>Note that while a Problem is unresolved it may continue to require attention. A record of resolved Problems may be maintained in a log.</t> </li> <li> <t>Note that there may be a Statewhichthat 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 oncemore),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).</t> </li> </ul> </dd> <dt>Cause:</dt> <dd><t>The Events (Detected or otherwise) that gave rise to a Fault/Problem.</t></dd> <dt>Incident:</dt><dd><t>A (Network)<dd><t>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 <xref target="I-D.ietf-nmop-network-incident-yang"/>.</t></dd>/>.</t> <!-- [rfced] Section 3.2: We see that [I-D.ietf-nmop-network-incident-yang] uses (mostly) "network incident", "customer incident", and "incident management", while this document uses initial-capitalized forms for these terms. Would you (perhaps Qin Wu or Nigel Davis, as coauthors of this document as well as [I-D.ietf-nmop-network-incident-yang]) like to suggest that the initial-capitalized forms of these terms also be used in [I-D.ietf-nmop-network-incident-yang]? We see that this document is listed in the Informative References of that document. Original: Incident: A (Network) 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 [I-D.ietf-nmop-network-incident-yang]. --> </dd> <dt>Symptom:</dt> <dd><t>An observable Value, Change, State, Event, or Condition considered as an indication of a Problem or potential Problem.</t></dd> <dt>Anomaly:</dt><dd><t>A (Network)<dd><t>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 <xref target="I-D.ietf-nmop-network-anomaly-architecture" /> for more details.</t></dd> <dt>Alert:</dt> <dd><t>An indication of a Fault.</t></dd> <dt>Alarm:</dt> <dd><t>As specified in <xref target="RFC8632" />,an Alarmsignifies 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.</t></dd> </dl> </section> <section anchor="other" numbered="true" toc="default"> <name>Other Terms</name> <t>Three other terms may be helpful:</t> <dl newline="false" spacing="normal"> <dt>Intermittent:</dt> <dd><t>A State that is notcontinuous,continuous but that keeps recurring in some time frame.</t></dd> <dt>Transient:</dt> <dd><t>A State that is notcontinuous,continuous and that occurs once in some time frame.</t></dd> <dt>Recurrent:</dt> <dd><t>A Problem that is activelyresolved,resolved but that returns.</t></dd> </dl> </section> </section> <section anchor="explain" numbered="true" toc="default"> <name>Workflow Explanations</name> <t>This section aims to add information about the relationship between the terms defined in <xref target="core" /> in the context of network fault and problem management. The text and figures here are for explanation and are not normative for the definition of terms.</t> <t>The relationship between Resources and Characteristics is shown in <xref target="systemfig" />. Note that there is a 1:n relationship between a Network system andResources,Resources and between Resources and Characteristics: For clarity, this is not shownonin thefigure for clarity.</t>figure.</t> <figure anchor="systemfig"> <name>Resources and Characteristics</name> <artwork align="center" name="" type=""alt=""> <![CDATA[alt=""><![CDATA[ Characteristics ^ | Resources ^ | Network system]]> </artwork>]]></artwork> </figure> <t>The Value of a Characteristic of a Resource may change over time. Specific Changes in Value may be noticed at a specific time (as digital Changes), Detected, and treated as Events. This is shown on theleftleft-hand side of <xref target="characterfig" />.</t> <t>The center of <xref target="characterfig" /> shows how the Value of a Characteristic may change over time. The Value may be Detected at specific times or periodically and give rise to Conditions that are States (and consequently State Changes).</t> <t>In practice, the Characteristic may vary in an analog manner over time as shown on the right-hand side of <xref target="characterfig" />. The Value can be read or reported (i.e., Detected) periodically leading to analog Values that may be deemed Relevant Values, or it may be evaluated over time as shown in <xref target="thresholdfig"/>.</t>/>. <!-- [rfced] Section 4: It seems odd that Figure 6 is cited before Figure 2 appears and before any mention of Figure 3. Would you like to move Figure 6 so that it appears just after Figure 2? It would then be renumbered as Figure 3, and the rest of the figures would be renumbered accordingly. Original: In practice, the Characteristic may vary in an analog manner over time as shown on the right-hand side of Figure 2. The Value can be read or reported (i.e., Detected) periodically leading to analog Values that may be deemed Relevant Values, or may be evaluated over time as shown in Figure 6. ( Contents of Figure 2 ) Figure 2: Characteristics and Changes Figure 3 shows the workflow progress for Events. As noted above, an Suggested: In practice, the Characteristic may vary in an analog manner over time as shown on the right-hand side of Figure 2. The Value can be read or reported (i.e., Detected) periodically leading to analog Values that may be deemed Relevant Values, or it may be evaluated over time as shown in Figure 3. ( Contents of Figure 2 ) Figure 2: Characteristics and Changes ( Contents of Figure 3 ) Figure 3: Counts, Thresholds, and Values Figure 3 shows the workflow progress for Events. As noted above, an --> </t> <figure anchor="characterfig"> <name>Characteristics and Changes</name> <artwork align="center" name="" type=""alt=""> <![CDATA[alt=""><![CDATA[ Event State Value Condition ^ ^ ^ Detect : Detect : Detect : : : : ^ ^ ^ ^ ^ /\ : : : : : / \ : : : : : /\ / \ __ __ _____ / \/ | | | | /\/ __| |__ ____| |____ / Change at a time Change over time Change over time]]> </artwork>]]></artwork> </figure> <!-- [rfced] Figures 2 and 6: We see "Change at a time" and "Change over time" in Figure 2 but "Change at a Time" and "Change over Time" in Figure 6. Would you like capitalization to be consistent? If yes, please specify which style is preferred. If you'd like to title case, may we change "Evaluated over time" in Figure 6 to "Evaluated over Time"? Original: Change at a time Change over time Change over time ... | Evaluated | | over time | ... Change at a Time Change over Time --> <t><xref target="eventfig" /> shows the workflow progress for Events. As noted above, an Event is a Change in the Value of a Characteristic at a time. The Event may be evaluated (considering policy, relative to a specific perspective, with a view to intent, and in relation to other Events, States, and Values) to determine if it is an Occurrence and possibly to indicate a Change of State. An Occurrence may be undesirable (a Fault) and that can cause an Alert to be generated, may be evidence of a Problem and could directly indicate a Cause. In some cases, an Alert may give rise to an Alarm highlighting the potential or actual presence of aProblem.</t>Problem. <!-- [rfced] Section 4: This sentence does not parse. If the suggested text is not correct, please clarify. Original: An Occurrence may be undesirable (a Fault) and that can cause an Alert to be generated, may be evidence of a Problem and could directly indicate a Cause. Suggested: An Occurrence may be undesirable (a Fault); this can cause an Alert to be generated, may be evidence of a Problem, and could directly indicate a Cause. --> </t> <figure anchor="eventfig"> <name>Event and Dependent Terms</name> <artwork align="center" name="" type=""alt=""> <![CDATA[alt=""><![CDATA[ Alert - - - > Alarm ^ | | -----> Cause | | |----------> Problem | | Fault ^ | | | Occurrence ^ | |----------> State | | Event]]> </artwork>]]></artwork> </figure> <t>Parallel to the workflow for Events, <xref target="statefig" /> shows the workflow progress for States. As shown in <xref target="characterfig" />, Change noted at a particular time gives rise to State. The State may be deemed to have Relevance considering policy, relative to a specific perspective, with a view to intent, and in relation to other Events, States, and Values. A Relevant State may be deemed a Problem, or it may indicate a Problem or potentialProblem.</t>Problem. <!-- [rfced] Section 4: Is there a distinction between "may be deemed a Problem" and "may indicate a Problem", as they seem to mean basically the same thing. Will this sentence be clear to readers? Original: A Relevant State may be deemed a Problem, or may indicate a Problem or potential Problem. --> </t> <t>Problems may be considered based on Symptoms and may map directly or indirectly to Causes. An Incident results from one or more Problems. An Alarm may be raised as the result of a Problem, and the transition to an Alarmed state may give rise to anAlert.</t>Alert. <!-- [rfced] Section 4: Should "Alarmed state" be "Alarm State" here? We ask because we see "an Alarm signifies an undesirable" State" in Section 3.2. Original: An Alarm may be raised as the result of a Problem, and the transition to an Alarmed state may give rise to an Alert. --> </t> <figure anchor="statefig"> <name>State and Dependent Terms</name> <artwork align="center" name="" type=""alt=""> <![CDATA[alt=""><![CDATA[ Alarm - - -> Alert ^ | ------> Incident | | | | ---> Cause | | | Problem---------> Symptom ^ | | Relevance | | State]]> </artwork>]]></artwork> </figure> <t><xref target="consolidationfig" /> shows how Faults and Problems may be consolidated to determine the Causes. The arrows show how one item may give rise to another.</t> <t>A Cause can be indicated by or determined from Faults, Problems, and Symptoms. It may be that one Cause points to another, and it can also be considered as a Symptom. The determination of Causes can consider multiple inputs. An Incident results from one or more Problems.</t> <figure anchor="consolidationfig"> <name>Consolidation of Symptoms and Causes</name> <artwork align="center" name="" type=""alt=""> <![CDATA[alt=""><![CDATA[ --------- ------------- | | | ----------> | Symptom | | | | | | | --------- v | ^ --------- | ------->| Cause |<--------- | | --------- | | | ^ | | | | | | | | | --- | | | | | --------- --------- ---------- | Fault |------------------->| Problem |------->| Incident | --------- --------- ----------]]> </artwork>]]></artwork> </figure> <t><xref target="thresholdfig" /> shows how thresholds are important in the consideration of analog Values and Events. The arrows in the figure show how one item may give rise to or utilize another. The use of threshold-driven Events and States (and the Alerts that they might give rise to) must be treated with caution to dampen any "flapping" (so that consistent States may be observed) and to avoid overwhelming management processes or systems. Analog Values may be read or notified from the Resource and could transition a threshold, be deemed Relevant Values, or be evaluated over time. Events may be counted, and the Count may cross a threshold or reach a Relevant Value.</t> <t>The Threshold Process may be implementation specific and subject to policies. When a threshold is crossed and any other conditions are matched, an Event may be determined and may be treated like any other Event. <!-- [rfced] Section 4: a) We see "threshold" but "Threshold Process" in these two paragraphs. Because "threshold" is not a term defined in this document, we suggest the lowercase form "threshold process" in the text, but please advise. Original: Figure 6 shows how thresholds are important in the consideration of analog Values and Events. The arrows in the figure show how one item may give rise to or utilize another. The use of threshold-driven Events and States (and the Alerts that they might give rise to) must be treated with caution to dampen any "flapping" (so that consistent States may be observed) and to avoid overwhelming management processes or systems. Analog Values may be read or notified from the Resource and could transition a threshold, be deemed Relevant Values, or evaluated over time. Events may be counted, and the Count may cross a threshold or reach a Relevant Value. The Threshold Process may be implementation-specific and subject to policies. When a threshold is crossed and any other conditions are matched, an Event may be determined, and treated like any otherEvent.</t>Event. b) We had trouble following the purpose of the comma after "determined" here. We removed it, per "Specific Changes in Value may be noticed at a specific time (as digital Changes), Detected, and treated as Events" seen earlier in this section. If this is incorrect, please clarify what "may" refers to in this sentence. Also, should "conditions" be "Conditions" here, as we see "give rise to Conditions that are States" in the second paragraph after Figure 1? Original: When a threshold is crossed and any other conditions are matched, an Event may be determined, and treated like any other Event. Currently (guessing "may be treated" as opposed to "will be treated" or otherwise): When a threshold is crossed and any other conditions are matched, an Event may be determined and may be treated like any other Event. --> </t> <figure anchor="thresholdfig"> <name>Counts, Thresholds, and Values</name> <artwork align="center" name="" type=""alt=""> <![CDATA[alt=""><![CDATA[ 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]]> </artwork>]]></artwork> </figure> </section> <section anchor="security-considerations" numbered="true" toc="default"> <name>Security Considerations</name> <t>This document specifies terminology and has no direct effect on the security of implementations or deployments. However, protocol solutions and management models need to be aware of several aspects:</t> <ul> <li> <t>The exposure of information pertaining to Faults and Problems may make available knowledge of the internal workings of a network (inparticularparticular, its vulnerabilities) that may be of use to an attacker.</t> </li> <li> <t>Systems that generate management information (messages, notifications, etc.) when Faultsoccur,occur may be attacked by causing them to generate so much information that the system that manages the network is swamped and unable to properly manage the network.</t> </li> <li> <t>Reporting false information about Faults (or masking reports of Faults) may cause the system that manages the network to function incorrectly.</t> </li> </ul> </section> <section anchor="privacy-considerations" numbered="true" toc="default"> <name>Privacy Considerations</name> <t>Network fault and problem management should preserve user privacy by not exposing user data or information about end-user activities.</t> <t>Network Telemetry involves observing network traffic and collecting operational data from the network, while Network Monitoring is the process of keeping records of data gathered in Network Telemetry. Therefore, it is possible that the data observed and collected includesusers'users' privacy information. Such information must be protected and controlled to avoid exposure tounauthorisedunauthorized parties. Particular care may need to be exercised over stores of such informationwhichthat might be accessed at any time (including far into thefuture).</t>future). </t> <t>Additionally, a network operator will be concernedto keepabout keeping control of all information about Faults to protect their own privacy and the details of how they operate their network.</t> </section> <section anchor="iana-considerations" numbered="true" toc="default"> <name>IANA Considerations</name> <t>This documentmakeshas norequests forIANAaction.</t>actions.</t> </section> </middle> <back> <displayreference target="I-D.ietf-nmop-network-anomaly-architecture" to="Net-Anomaly-Arch"/> <displayreference target="I-D.ietf-nmop-network-incident-yang" to="Net-Incident-Mgmt-YANG"/> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3877.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6632.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8632.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9232.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9315.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9417.xml"/> <!-- draft-ietf-nmop-network-anomaly-architecture (I-D Exists) (Did "long way" to fix Alex Huang Feng's surname) --> <reference anchor="I-D.ietf-nmop-network-anomaly-architecture"> <front> <title>A Framework for a Network Anomaly Detection Architecture</title> <author initials="T." surname="Graf" fullname="Thomas Graf"> <organization>Swisscom</organization> </author> <author initials="W." surname="Du" fullname="Wanting Du"> <organization>Swisscom</organization> </author> <author initials="P." surname="Francois" fullname="Pierre Francois"> <organization>INSA-Lyon</organization> </author> <author initials="A." surname="Huang Feng" fullname="Alex Huang Feng"> <organization>INSA-Lyon</organization> </author> <date month="November" day="21" year="2025" /> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-nmop-network-anomaly-architecture-06" /> </reference> <!-- draft-ietf-nmop-network-incident-yang (I-D Exists) --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-nmop-network-incident-yang.xml"/> </references> <section anchor="acknowledgments" numbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors would like to thank <contact fullname="Med Boucadair"/>, <contact fullname="Wanting Du"/>, <contact fullname="Joe Clarke"/>, <contact fullname="Javier Antich"/>, <contact fullname="Benoit Claise"/>, <contact fullname="Christopher Janz"/>, <contact fullname="Sherif Mostafa"/>, <contact fullname="Kristian Larsson"/>, <contact fullname="Dirk Hugo"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Hilarie Orman"/>, <contact fullname="Stewart Bryant"/>, <contact fullname="Bo Wu"/>, <contact fullname="Paul Kyzivat"/>, <contact fullname="Jouni Korhonen"/>, <contact fullname="Reshad Rahman"/>, <contact fullname="Rob Wilton"/>, <contact fullname="Mahesh Jethanandani"/>, <contact fullname="Tim Bray"/>, <contact fullname="Paul Aitken"/>, and <contact fullname="Deb Cooley"/> for their helpful comments. <!-- [rfced] Acknowledgments: Should Dirk Hugo be listed here as "Dirk Von Hugo"? We ask because we see a "Dirk Von Hugo" listed in several post-6000 RFCs but not a "Dirk Hugo". Also, we see "Dirk Von Hugo" on <https://datatracker.ietf.org/person/dirkvhugo@gmail.com>. Original: The authors would like to thank Med Boucadair, Wanting Du, Joe Clarke, Javier Antich, Benoit Claise, Christopher Janz, Sherif Mostafa, Kristian Larsson, Dirk 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 helpfulcomments.</t>comments. --> </t> <t>Special thanks to the team that met at a side meeting atIETF-120IETF 120 to discuss some of the thorny issues:</t> <ul spacing="compact"><li>Benoit Claise</li> <li>Watson Ladd</li> <li>Brad Peters</li> <li>Bo Wu</li> <li>Georgios Karagiannis</li> <li>Olga Havel</li> <li>Vincenzo Riccobene</li> <li>Yi Lin</li> <li>Jie Dong</li> <li>Aihua Guo</li> <li>Thomas Graf</li> <li>Qin Wu</li> <li>Chaode Yu</li> <li>Adrian Farrel</li><li><t><contact fullname="Benoit Claise"/></t></li> <li><t><contact fullname="Watson Ladd"/></t></li> <li><t><contact fullname="Brad Peters"/></t></li> <li><t><contact fullname="Bo Wu"/></t></li> <li><t><contact fullname="Georgios Karagiannis"/></t></li> <li><t><contact fullname="Olga Havel"/></t></li> <li><t><contact fullname="Vincenzo Riccobene"/></t></li> <li><t><contact fullname="Yi Lin"/></t></li> <li><t><contact fullname="Jie Dong"/></t></li> <li><t><contact fullname="Aihua Guo"/></t></li> <li><t><contact fullname="Thomas Graf"/></t></li> <li><t><contact fullname="Qin Wu"/></t></li> <li><t><contact fullname="Chaode Yu"/></t></li> <li><t><contact fullname="Adrian Farrel"/></t></li> </ul> </section></middle> <back> <references> <name>Informative References</name> &RFC3877; &RFC6632; &RFC8342; &RFC8632; &RFC9232; &RFC9315; &RFC9417; &I-D.ietf-nmop-network-anomaly-architecture; &I-D.ietf-nmop-network-incident-yang; </references></back> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide at <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </rfc>