rfc9940.original.xml		rfc9940.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='UTF-8'?>
	<!DOCTYPE rfc [		<!-- pre-edited by ST 09/04/25 -->
	<!ENTITY RFC3877 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R		<!-- pre-edited by ST 09/11/25 -->
	FC.3877.xml">		<!-- reference review by TH 10/07/25 -->
	<!ENTITY RFC6632 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
	FC.6632.xml">
	<!ENTITY RFC8342 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
	FC.8342.xml">
	<!ENTITY RFC8632 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
	FC.8632.xml">
	<!ENTITY RFC9232 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
	FC.9232.xml">
	<!ENTITY RFC9315 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
	FC.9315.xml">
	<!ENTITY RFC9417 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.R
	FC.9417.xml">
	<!ENTITY I-D.ietf-nmop-network-anomaly-architecture SYSTEM "http://xml2rfc.iet		<!DOCTYPE rfc [
	f.org/public/rfc/bibxml3/reference.I-D.ietf-nmop-network-anomaly-architecture">		<!ENTITY nbsp "&#160;">
	<!ENTITY I-D.ietf-nmop-network-incident-yang SYSTEM "http://xml2rfc.ietf.org/p		<!ENTITY zwsp "&#8203;">
	ublic/rfc/bibxml3/reference.I-D.ietf-nmop-network-incident-yang">		<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
	]>		]>
	<?rfc toc="yes"?>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	<?rfc tocompact="yes"?>		-ietf-nmop-terminology-23" number="9940" consensus="true" category="info" obsole
	<?rfc tocdepth="3"?>		tes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth
	<?rfc tocindent="yes"?>		="3" symRefs="true" sortRefs="true" version="3">
	<?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" category="info" obsoletes="" updates="" submissionTyp
	e="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="t
	rue" version="3">
	<front>		<front>
	<title abbrev="Network Fault Terminology">Some Key Terms for Network Fault a nd Problem Management</title>		<title abbrev="Network Fault Terminology">Some Key Terms for Network Fault a nd Problem Management</title>
			<seriesInfo name="RFC" value="9940"/>
	<seriesInfo name="Internet-Draft" value="draft-ietf-nmop-terminology-23"/>
	<author initials="N." surname="Davis" fullname="Nigel Davis" role="editor">		<author initials="N." surname="Davis" fullname="Nigel Davis" role="editor">
	<organization>Ciena</organization>		<organization>Ciena</organization>
	<address>		<address>
	<postal>		<postal>
	<street/>
	<city/>
	<country>United Kingdom</country>		<country>United Kingdom</country>
	</postal>		</postal>
	<email>ndavis@ciena.com</email>		<email>ndavis@ciena.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="A." surname="Farrel" fullname="Adrian Farrel" role="editor ">		<author initials="A." surname="Farrel" fullname="Adrian Farrel" role="editor ">
	<organization>Old Dog Consulting</organization>		<organization>Old Dog Consulting</organization>
	<address>		<address>
	<postal>		<postal>
	<street/>
	<city/>
	<country>United Kingdom</country>		<country>United Kingdom</country>
	</postal>		</postal>
	<email>adrian@olddog.co.uk</email>		<email>adrian@olddog.co.uk</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Thomas Graf" initials="T" surname="Graf">		<author fullname="Thomas Graf" initials="T" surname="Graf">
	<organization>Swisscom</organization>		<organization>Swisscom</organization>
	<address>		<address>
	<postal>		<postal>
	skipping to change at line 92 ¶		skipping to change at line 73 ¶
	</address>		</address>
	</author>		</author>
	<author initials="C." surname="Yu" fullname="Chaode Yu">		<author initials="C." surname="Yu" fullname="Chaode Yu">
	<organization>Huawei Technologies</organization>		<organization>Huawei Technologies</organization>
	<address>		<address>
	<email>yuchaode@huawei.com</email>		<email>yuchaode@huawei.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2025"/>		<!-- [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.
			-->
			<date year="2026" month="February"/>
			<area>OPS</area>
			<workgroup>nmop</workgroup>
	<keyword>Problem</keyword>		<keyword>Problem</keyword>
	<keyword>Event</keyword>		<keyword>Event</keyword>
	<keyword>Fault</keyword>		<keyword>Fault</keyword>
	<keyword>Occurrence</keyword>		<keyword>Occurrence</keyword>
	<keyword>Incident</keyword>		<keyword>Incident</keyword>
	<keyword>Anomally</keyword>		<keyword>Anomaly</keyword>
	<keyword>Symptom</keyword>		<keyword>Symptom</keyword>
	<keyword>Alert</keyword>		<keyword>Alert</keyword>
	<keyword>Alarm</keyword>		<keyword>Alarm</keyword>
	<abstract>		<abstract>
	<t>This document sets out some terms that are fundamental to a common unde rstanding		<t>This document sets out some terms that are fundamental to a common unde rstanding
	of network fault and problem management within the IETF.</t>		of network fault and problem management within the IETF.</t>
	<t>The purpose of this document is to bring clarity to discussions and oth er work		<t>The purpose of this document is to bring clarity to discussions and oth er work
	related to network fault and problem management, in particular to YANG data models and management protocols		related to network fault and problem management -- in particular, to YA NG data models and management protocols
	that report, make visible, or manage network faults and problems.</t>		that report, make visible, or manage network faults and problems.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction" numbered="true" toc="default">		<section anchor="introduction" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>Successful operation of large networks depends on effective network man agement. This requires a		<t>Successful operation of large networks depends on effective network man agement. This requires a
	virtuous circle of network control, network observability, network anal ytics, network assurance, and back to		virtuous circle of network control, network observability, network anal ytics, network assurance, and back to
	network control. Network fault and problem management <xref target="RFC 6632" /> is an important aspect of network management and		network control. Network fault and problem management <xref target="RFC 6632" /> 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		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 tha t have a negative effect on the network&apos;s ability to		network. The intention of this document is to focus on those events tha t 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		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		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 expecte		determine the causes of problems and to work toward recovery of expecte
	d network behavior.</t>		d network 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		<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		management system, such as YANG data models or management protocols. It is important that
	a common terminology is used so that there is a clear understanding of		a common terminology be used so that there is a clear understanding of
	how the		how the
	elements of the management and control solutions fit together, and how		elements of the management and control solutions fit together and how f
	faults and		aults and
	problems will be handled.</t>		problems will be handled.</t>
	<t>This document sets out some terms that are fundamental to a common unde rstanding of network fault and		<t>This document sets out some terms that are fundamental to a common unde rstanding of network fault and
	problem management. While "faults" and "problems" are concepts that ap ply at all levels of technology in		problem management. While "faults" and "problems" are concepts that ap ply at all levels of technology in
	the Internet, the scope of this document is restricted to the network l		the Internet, the scope of this document is restricted to the network l
	ayer and below, hence this document		ayer and below; hence, this document
	is specifically about "network fault and problem management." The conce		is specifically about "network fault and problem management". The conce
	pt of "incidents" is also touched on		pt of "incidents" is also touched on
	in this document, where an incident results from one or more problems a nd is the disruption of a network		in this document, where an incident results from one or more problems a nd is the disruption of a network
	service.</t>		service.</t>
	<t>Note that some useful terms are defined in <xref target="RFC3877" /> an d <xref target="RFC8632" />. The		<t>Note that some useful terms are defined in <xref target="RFC3877" /> an d <xref target="RFC8632" />. The
	definitions in this document are informed by those documents, but they are not dependent on that prior		definitions in this document are informed by those documents, but they are not dependent on that prior
	work.</t>		work.</t>
	</section>		</section>
	<section anchor="usage" numbered="true" toc="default">		<section anchor="usage" numbered="true" toc="default">
	<name>Usage of Terms</name>		<name>Usage of Terms</name>
	<t>The terms defined in this document are intended for consistent use with in the IETF in the scope of		<t>The terms defined in this document are intended for consistent use with in the IETF in the scope of
	network fault and problem management. Where similar concepts are descri bed in other bodies, an attempt has been		network fault and problem management. Where similar concepts are descri bed in other bodies, an attempt has been
	made to harmonize with those other descriptions, but there is care need ed where terms are not used consistently		made to harmonize with those other descriptions, but care is needed whe re terms are not used consistently
	between bodies or where terms are applied outside the network layer. If other bodies find the terminology		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>		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 i n other documents. Other terms are defined		<t>The purpose of this document is to define the following terms for use i n other documents. Other terms are defined
	to enable those definitions and may also be used by other documents, al though that is not the principal purpose of		to enable those definitions and may also be used by other documents, al though that is not the principal purpose of
	their definitions here.</t>		their definitions here.</t>
	<ul spacing="compact">		<ul spacing="compact">
	<li>Event</li>		<li>Event</li>
	<li>State</li>		<li>State</li>
	<li>Fault</li>		<li>Fault</li>
	<li>Problem</li>		<li>Problem</li>
	<li>Symptom</li>		<li>Symptom</li>
	<li>Cause</li>		<li>Cause</li>
	<li>Alert</li>		<li>Alert</li>
	<li>Alarm</li>		<li>Alarm</li>
	</ul>		</ul>
	<t>When other documents make use of the terms as defined in this document, it is suggested here that such uses should		<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 in this document to help distinguish them from colloquial uses, and should		use capitalization of the terms as done in this document to help distin guish them from colloquial uses and should
	include an early section listing the terms inherited from this document with a citation.</t>		include an early section listing the terms inherited from this document with a citation.</t>
	</section>		</section>
	<section anchor="terms" numbered="true" toc="default">		<section anchor="terms" numbered="true" toc="default">
	<name>Terminology</name>		<name>Terminology</name>
	<t>This section contains key terms. It is split into three subsections.</t >		<t>This section contains key terms. It is split into three subsections.</t >
	<ul>		<ul>
	<li>		<li>
	<t><xref target="context" /> contains terms that help to set the conte xt for network fault and problem management systems.</t>		<t><xref target="context" /> contains terms that help set the context for network fault and problem management systems.</t>
	</li>		</li>
	<li>		<li>
	<t><xref target="core" /> includes specific and detailed core terms th at will be used in other documents that describe elements of		<t><xref target="core" /> includes specific and detailed core terms th at will be used in other documents that describe elements of
	the network fault and problem management systems.</t>		the network fault and problem management systems.</t>
	</li>		</li>
	<li>		<li>
	<t><xref target="other" /> provides three further terms that may be he lpful.</t>		<t><xref target="other" /> provides three further terms that may be he lpful.</t>
	</li>		</li>
	</ul>		</ul>
	skipping to change at line 210 ¶		skipping to change at line 234 ¶
	<t>This section includes some terminology that helps describe the contex t for the rest of this work. The terms may be viewed as a		<t>This section includes some terminology that helps describe the contex t for the rest of this work. The terms may be viewed as a
	cascaded sequence of processes, starting with Network Telemetry and b uilding to Network Observability. The definitions are deliberately kept		cascaded sequence of processes, starting with Network Telemetry and b uilding 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)		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>		should be highlighted clearly in those documents.</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>Network Telemetry:</dt>		<dt>Network Telemetry:</dt>
	<dd><t>This is defined in <xref target="RFC9232" /> and describes t he process of collecting operational network data categorized		<dd><t>This is defined in <xref target="RFC9232" /> and describes t he 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		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		Network Telemetry process does not contain any data related to service definitions
	(i.e., "intent" per Section 3.1 of <xref target="RFC9315" />		(i.e., "intent" per <xref target="RFC9315" section="3.1"/>).
	).</t></dd>		</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 [RFC9315]). -->
			</dd>
	<dt>Network Monitoring:</dt>		<dt>Network Monitoring:</dt>
	<dd><t>This is the process of keeping a continuous record of functi ons related to a network topology. It involves tracking		<dd><t>This is the process of keeping a continuous record of functi ons related to a network topology. It involves tracking
	various aspects such as traffic patterns, device health, per		various aspects such as traffic patterns, device health, per
	formance metrics, and overall network behaviour. This approach		formance metrics, and overall network behavior. This approach
	differentiates network monitoring from resource or device mo		differentiates network monitoring from resource or device mo
	nitoring, which focuses on individual components or resources		nitoring, which focuses on individual resources or components
	(<xref target="core"/>).</t></dd>		(<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
			(Section 3.2). -->
			</dd>
	<dt>Network Analytics:</dt>		<dt>Network Analytics:</dt>
	<dd><t>This is the process of deriving analytical insights from ope rational network data. A process could be executed by		<dd><t>This is the process of deriving analytical insights from ope rational network data. A process could be executed by
	a piece of software, a system, or a human that analyzes oper ational data and outputs new analytical data related to the operational		a piece of software, a system, or a human that analyzes oper ational data and outputs new analytical data related to the operational
	data, for example, a symptom.</t></dd>		data -- for example, a symptom.</t></dd>
	<dt>Network Observability:</dt>		<dt>Network Observability:</dt>
	<dd><t>This is the process of enabling network behavioral assessmen t through analysis of observed operational network data (logs, alarms, traces,		<dd><t>This is the process of enabling network behavioral assessmen t 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		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		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 a		outcome of the observability processes is identification and analysis of deviations in observed state versus the expected state of a
	network.</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>		</dl>
	<t>Thus, there is a cascaded sequence where the following relationships apply:</t>		<t>Thus, there is a cascaded sequence where the following relationships apply:</t>
	<ul>		<ul>
	<li>Network Telemetry is the process of collecting operational data from a network.</li>		<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 o f data gathered in Network Telemetry.</li>		<li>Network Monitoring is the process of creating/keeping a record o f 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 Analytics is the process of deriving insight through the data recorded in Network Monitoring.</li>
	<li>Network Observability is the process of enabling behavioral asse ssment of a network through Network Analytics.</li>		<li>Network Observability is the process of enabling behavioral asse ssment of a network through Network Analytics.</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="core" numbered="true" toc="default">		<section anchor="core" numbered="true" toc="default">
	<name>Core Terms</name>		<name>Core Terms</name>
	<t>The terms are presented below in an order that is intended to flow su		<!-- [rfced] Section 3.2: To achieve parallelism in the list
	ch that it is possible		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 presented in an order that is intended
			to flow such that it is possible
	to gain understanding reading top to bottom. The figures and explana tions in <xref target="explain" />		to gain understanding reading top to bottom. The figures and explana tions in <xref target="explain" />
	may aid understanding the terms set out here.</t>		may aid understanding the terms set out here.</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>Resource:</dt>		<dt>Resource:</dt>
	<dd><t>An element of a network system.</t>		<dd><t>An element of a network system.
	<t>Resource is a recursive concept so that a Resource may be a
	collection of		<!-- [rfced] Sections 3.2 and 4: We see one instance of "network
	other Resources (for example, a network node comprises a col		system" in Section 3.2 but two instances of "Network system" in
	lection of network interfaces).</t></dd>		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 network 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>		<dt>Characteristic:</dt>
	<dd><t>Observable or measurable aspect or behavior associated with a Resource.</t>		<dd><t>Observable or measurable aspect or behavior associated with a Resource.</t>
	<ul>		<ul>
	<li>		<li>
	<t>A Characteristic may be considered to be built on facts (see		<t>A Characteristic may be considered to be built on facts (see
	'Value', below) and the contexts and descriptors		'Value', below) and the contexts and descriptors that identify
	that identify and give meaning to the facts.</t>		and give meaning to the facts.</t>
	</li>		</li>
	<li>		<li>
	<t>The term "Metric" <xref target="RFC9417" /> is another w		<t>The term "Metric" <xref target="RFC9417" /> is another w
	ord for a measurable Characteristic which may also		ord
	be thought of as analogous to a 'variable'.</t>		for a measurable Characteristic which may also be thought of as
			analogous to a '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>		</li>
	</ul></dd>		</ul></dd>
	<dt>Value:</dt>		<dt>Value:</dt>
	<dd><t>A Value is a measure of a Characteristic associated with a		<dd><t>A measure of a Characteristic associated with a
	Resource. It may be in the form of a categorization (e.g., h		Resource. It may be in the form of a categorization (e.g., high
	igh or low),		or low), an integer (e.g., a count or gauge), or a reading of a
	an integer (e.g., a count or gauge), or a reading of a conti		continuous variable (e.g., an analog measurement), etc.</t>
	nuous variable (e.g., an
	analog measurement), etc.</t></dd>		<!-- [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>		<dt>Change:</dt>
	<dd><t>In the context of Network Monitoring, a Change is the variat		<dd><t>In the context of Network Monitoring, the
	ion in the Value of a		variation in the Value of a Characteristic associated with a
	Characteristic associated with a Resource and may arise over		Resource. A Change may arise over a period of time.</t>
	a period of time.</t>		<ul>
	<ul>		<li>
	<li>		<t>Not all Changes are noteworthy (i.e., they do not have Relev
	<t>Not all Changes are noteworthy (i.e., they do not have R		ance).</t>
	elevance).</t>		</li>
	</li>		<li>
	<li>		<t>Perception of Change depends upon Detection, the sampling ra
	<t>Perception of Change depends upon Detection, the samplin		te/accuracy/detail, and perspective.</t>
	g rate/accuracy/detail, and perspective.</t>		</li>
	</li>		<li>
	<li>		<t>It may be helpful to qualify this as "Value Change" because t
	<t>It may be helpful to qualify this as "Value Change" beca		he English word "change" is often heavily used.</t>
	use the English word "change" is often heavily used.</t>		</li>
	</li>		</ul>
	</ul>		</dd>
	</dd>
	<dt>Event:</dt>		<dt>Event:</dt>
	<dd><t>The variation in Value of a Characteristic of a Resource at		<dd><t>The variation in Value of a Characteristic of a Resource
	a distinct moment in		at a distinct moment in time (i.e., the period is
	time (i.e., the period is negligible).</t>		negligible).
	<ul>
	<li>		<!-- [rfced] Section 3.2: Is the period (of time) always negligible,
	<t>Compared with a Change, which may be over a period of ti		or should "i.e.," be "e.g.," here?
	me, an Event happens at a
	distinct moment in time. Thus, an Event may be the obser		Original:
	vation of a Change.</t>		Event: The variation in Value of a Characteristic of a Resource at a
	</li>		distinct moment in time (i.e., the period is negligible). -->
	</ul>
	</dd>		</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>		<dt>Condition:</dt>
	<dd><t>A Condition is an interpretation of the Values of a set of o		<dd><t>An interpretation of the Values of a set of
	ne or more Characteristics of a Resource (with		one or more Characteristics of a Resource (with respect to
	respect to working order or some other aspect relevant to th		working order or some other aspect relevant to the Resource
	e Resource purpose/application), for		purpose/application) -- for example, "low available memory". Thus,
	example "low available memory". Thus, it is the output of a		it is the output of a function applied to a set of one or more
	function applied to a set of one or more variables.</t></dd>		variables.</t></dd>
	<dt>State:</dt>		<dt>State:</dt>
	<dd><t>A particular Condition that a Resource has (i.e., it is in a		<dd><t>A particular Condition that a Resource has (i.e., it is in
	State) at a specific time.		a State) at a specific time. For example, a router may report
	For example, a router may report the total amount of memory		the total amount of memory it has and how much is free. These
	it has, and how much is free. These are the		are the Values of two Characteristics of a Resource. These Values
	Values of two Characteristics of a Resource. These Values ca		can be interpreted to determine the Condition of the Resource,
	n be interpreted to determine the Condition		and that may determine the State of the router, such as shortage
	of the Resource, and that may determine the State of the rou		of memory.</t>
	ter, such as shortage of memory.</t>		<ul>
	<ul>		<li>
	<li>		<t>While a State may be observed at a specific moment in time,
	<t>While a State may be observed at a specific moment in ti		it
	me, it is actually		is actually determined by summarizing measurement over time in a
	determined by summarizing measurement over time in a pro		process sometimes called State compression.</t>
	cess sometimes		</li>
	called State compression.</t>		<li>
	</li>		<t>It may be helpful to qualify this as "Resource State" to mak
	<li>		e
	<t>It may be helpful to qualify this as "Resource State" to		clear the distinction between this and other uses of "state" such
	make clear the distinction between this and		as "protocol state".</t>
	other uses of "state" such as "protocol state".</t>		</li>
	</li>		<li>
	<li>		<t>This term may be contrasted with "Operational State" as used
	<t>This term may be contrasted with "Operational State" as		in <xref target="RFC8342" />. For example, the state of a link
	used in <xref target="RFC8342" />. For example,		might be up/down/degraded, but the operational state of the link
	the state of a link might be up/down/degraded, but the o		would include a collection of Values of Characteristics of the
	perational state of link would include a collection of		link.
	Values of Characteristics of the link.</t>
	</li>		<!-- [rfced] Section 3.2: RFC 8342 uses the lowercase form
	</ul>		"operational state". Because this sentence says "as used in
	</dd>		[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 the link. -->
			</t>
			</li>
			</ul>
			</dd>
	<dt>Detect (hence Detected, Detection):</dt>		<dt>Detect (hence Detected, Detection):</dt>
	<dd><t>To notice the presence of something (State, Change, Event, a		<dd><t>To notice the presence of something (State, Change, Event, a
	ctivity, etc.).</t>		ctivity, etc.) and hence also to notice a Change (from the perspective of an
	<ul>		observer such as a monitoring system).</t>
	<li>		</dd>
	<t>Hence also to notice a Change (from the perspective of a
	n observer such as a monitoring system).</t>
	</li>
	</ul>
	</dd>
	<dt>Relevance:</dt>		<dt>Relevance:</dt>
	<dd><t>Consideration of an Event, State, or Value (through the appl ication of policy, relative		<dd><t>Consideration of an Event, State, or Value (through the appl ication of policy, relative
	to a specific perspective, intent, and in relation to other Events, States,		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		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 Releva		network. Note, for example, that not all Changes are Releva
	nt.</t>		nt.
	<ul>
	<li>		<!-- [rfced] Section 3.2: We had trouble following this sentence.
	<t>This term may also be used as "Relevant Event", "Relevant S		Should "relative to a specific perspective, intent, ..." be
	tate", or "Relevant Value".</t>		"relative to a specific perspective, with a view to intent, ..."
	</li>		per text seen twice in Section 4? If not, what do "relative to a
	</ul>		specific perspective" and "and in relation to other Events ..." refer
	</dd>		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>		<dt>Occurrence:</dt>
	<dd><t>A Relevant Event or a particular Relevant Change.</t>		<dd><t>A Relevant Event or a particular Relevant Change.</t>
	<ul>		<ul>
	<li>		<li>
	<t>An Occurrence may be an aggregation or abstraction of multi		<t>An Occurrence may be an aggregation or abstraction of multi
	ple fine-grain Events or Changes.</t>		ple fine-grained Events or Changes.
	</li>
			</t>
			</li>
	<li>		<li>
	<t>An Occurrence may occur at any macro or micro scale because		<t>An Occurrence may occur at any macro or micro scale because
	Resources are a recursive		Resources are a recursive concept, and may be perceived, depending
	concept, and may be perceived depending on the scope of obs		on the scope of observation (i.e., according to the level of
	ervation (i.e., according		Resource recursion that is examined). That is, Occurrences,
	to the level of Resource recursion that is examined). That		themselves, are a recursive concept.
	is, Occurrences, themselves
	are a recursive concept.</t>		<!-- [rfced] Section 3.2: Does "and may be perceived" refer to the
	</li>		Occurrence or the Resources in this sentence? If "Resources", we
	</ul>		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 recursive concept. -->
			</t>
			</li>
			</ul>
	</dd>		</dd>
	<dt>Fault:</dt>		<dt>Fault:</dt>
	<dd><t>An Occurrence (i.e., an Event or a Change) that is not desir		<dd><t>An Occurrence (i.e., an Event or a Change) that is not
	ed/required (as it may be indicative of a current or future		desired/required (as it may be indicative of a current or future
	undesired State). Thus, a Fault happens at a moment in time.		undesired State). Thus, a Fault happens at a moment in time. A
	A Fault can potentially be associated with a Cause. See		Fault can potentially be associated with a Cause. See <xref
	<xref target="RFC8632" /> for a more detailed discussion of		target="RFC8632" /> for a more detailed discussion of network
	network faults.</t>		faults.</t>
	<ul>		<ul>
	<li>		<li>
	<t>Note that there is a distinction between a Fault and a P		<t>Note that there is a distinction between a Fault and a Proble
	roblem that depends on context. For example, in a		m
	connectivity service where redundancy is present, a link		that depends on context. For example, in a connectivity service
	down is a Problem, but from the perspective of managing the		where redundancy is present, a link down is a Problem, but from
	network resources, a link down is a Fault. Likewise, fo		the perspective of managing the network resources, a link down is
	r example, in a router with two power supplies, if the		a Fault. Likewise, for example, in a router with two power
	backup power supply fails leaving the primary unprotecte		supplies, if the backup power supply fails leaving the primary
	d, this is a Problem.</t>		unprotected, this is a Problem.</t>
	</li>		</li>
	</ul>		</ul>
	</dd>		</dd>
	<dt>Problem:</dt>		<dt>Problem:</dt>
	<dd><t>A State that is undesirable and that may require remedial ac		<dd><t>A State that is undesirable and that may require remedial
	tion. A Problem cannot		action. A Problem cannot necessarily be associated with a
	necessarily be associated with a Cause. The resolution of a		Cause. The resolution of a Problem does not necessarily act on
	Problem does not necessarily		the thing that has the Problem.</t>
	act on the thing that has the Problem.</t>		<ul>
	<ul>		<li>
	<li>		<t>Note that there is a historic aspect to the concept of a
	<t>Note that there is a historic aspect to the concept of a		Problem. The current State may be operational, but there could
	Problem. The current State		have been a Fault that is unexplained, and the fact of that
	may be operational, but there could have been a Fault th		unexplained recent Fault is a Problem.</t>
	at is unexplained, and		</li>
	the fact of that unexplained recent Fault is a Problem.<		<li>
	/t>		<t>Note that while a Problem is unresolved it may continue to
	</li>		require attention. A record of resolved Problems may be
	<li>		maintained in a log.</t>
	<t>Note that while a Problem is unresolved it may continue		</li>
	to require attention. A		<li>
	record of resolved Problems may be maintained in a log.<		<t>Note that there may be a State that is considered to be a
	/t>		Problem from several perspectives. For example, consider a "loss
	</li>		of light" State that may cause multiple services to fail. In this
	<li>		example, a new State (the light recovers) may cause the Problem
	<t>Note that there may be a State which is considered to be		to be resolved from one perspective (the services are operational
	a Problem from several		once more) but may leave the Problem as unresolved (because the
	perspectives. For example, consider a "loss of light" St		loss of light has not been explained). Further, in this example,
	ate that may cause multiple		there could be another development (the reason for the temporary
	services to fail. In this example, a new State (the ligh		loss of light is traced to a microbend in the fiber that is
	t recovers) may		repaired) resulting in that unresolved Problem now being
	cause the Problem to be resolved from one perspective (t		resolved. But, in this example, this still leaves a further
	he services are operational		Problem unresolved (a microbend occurred, and that Problem is not
	once more), but may leave the Problem as unresolved (bec		resolved until it is understood how it occurred and a remedy is
	ause the loss of light has		put in place to prevent recurrence).</t>
	not been explained). Further, in this example, there cou		</li>
	ld be another development		</ul>
	(the reason for the temporary loss of light is traced to		</dd>
	a microbend in the fiber
	that is repaired) resulting in that unresolved Problem n
	ow being resolved. But, in
	this example, this still leaves a further Problem unreso
	lved (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>		<dt>Cause:</dt>
	<dd><t>The Events (Detected or otherwise) that gave rise to a Fault /Problem.</t></dd>		<dd><t>The Events (Detected or otherwise) that gave rise to a Fault /Problem.</t></dd>
	<dt>Incident:</dt>		<dt>Incident:</dt>
	<dd><t>A (Network) Incident is an undesired Occurrence such as an u nexpected interruption of a		<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 ser vice, or the below-target		network service, degradation of the quality of a network ser vice, or the below-target
	performance of a network service. An Incident results from o ne or more Problems, and a		performance of a network service. An Incident results from o ne or more Problems, and a
	Problem may give rise to or contribute to one or more Incide nts.		Problem may give rise to or contribute to one or more Incide nts.
	Greater discussion of Network Incident relationships, includ ing Customer Incidents and		Greater discussion of Network Incident relationships, includ ing Customer Incidents and
	Incident management, can be found in <xref target="I-D.ietf-		Incident management, can be found in <xref target="I-D.ietf-
	nmop-network-incident-yang" />.</t></dd>		nmop-network-incident-yang" />.</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>		<dt>Symptom:</dt>
	<dd><t>An observable Value, Change, State, Event, or Condition cons idered as an indication of a		<dd><t>An observable Value, Change, State, Event, or Condition cons idered as an indication of a
	Problem or potential Problem.</t></dd>		Problem or potential Problem.</t></dd>
	<dt>Anomaly:</dt>		<dt>Anomaly:</dt>
	<dd><t>A (Network) Anomaly is an unusual or unexpected Event or pat tern in network data in the		<dd><t>Also referred to as "(Network) Anomaly". An Anomaly is an un usual or unexpected Event or pattern in network data in the
	forwarding plane, control plane, or management plane that de viates from the normal,		forwarding plane, control plane, or management plane that de viates from the normal,
	expected behavior. See <xref target="I-D.ietf-nmop-network-a nomaly-architecture" />		expected behavior. See <xref target="I-D.ietf-nmop-network-a nomaly-architecture" />
	for more details.</t></dd>		for more details.</t></dd>
	<dt>Alert:</dt>		<dt>Alert:</dt>
	<dd><t>An indication of a Fault.</t></dd>		<dd><t>An indication of a Fault.</t></dd>
	<dt>Alarm:</dt>		<dt>Alarm:</dt>
	<dd><t>As specified in <xref target="RFC8632" />, an Alarm signifie s an undesirable State in a		<dd><t>As specified in <xref target="RFC8632" />, signifies an unde sirable State in a
	Resource that requires corrective action. From a management point of view,		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 tra nsition to this State		an Alarm can be seen as a State in its own right and the tra nsition to this State
	may result in an Alert being issued. The receipt of this Al ert		may result in an Alert being issued. The receipt of this Al ert
	may give rise to a continuous indication (to a human operato r) highlighting the		may give rise to a continuous indication (to a human operato r) highlighting the
	potential or actual presence of a Problem.</t></dd>		potential or actual presence of a Problem.</t></dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="other" numbered="true" toc="default">		<section anchor="other" numbered="true" toc="default">
	<name>Other Terms</name>		<name>Other Terms</name>
	<t>Three other terms may be helpful:</t>		<t>Three other terms may be helpful:</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>Intermittent:</dt>		<dt>Intermittent:</dt>
	<dd><t>A State that is not continuous, but keeps recurring in some t ime frame.</t></dd>		<dd><t>A State that is not continuous but that keeps recurring in so me time frame.</t></dd>
	<dt>Transient:</dt>		<dt>Transient:</dt>
	<dd><t>A State that is not continuous, and occurs once in some time frame.</t></dd>		<dd><t>A State that is not continuous and that occurs once in some t ime frame.</t></dd>
	<dt>Recurrent:</dt>		<dt>Recurrent:</dt>
	<dd><t>A Problem that is actively resolved, but returns.</t></dd>		<dd><t>A Problem that is actively resolved but that returns.</t></dd >
	</dl>		</dl>
	</section>		</section>
	</section>		</section>
	<section anchor="explain" numbered="true" toc="default">		<section anchor="explain" numbered="true" toc="default">
	<name>Workflow Explanations</name>		<name>Workflow Explanations</name>
	<t>This section aims to add information about the relationship between the terms defined in		<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 mana gement.		<xref target="core" /> in the context of network fault and problem mana gement.
	The text and figures here are for explanation and are not normative for the definition of terms.</t>		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		<t>The relationship between Resources and Characteristics is shown in
	<xref target="systemfig" />. Note that there is a 1:n relationship betw		<xref target="systemfig" />. Note that there is a 1:n relationship betw
	een Network		een a Network
	system and Resources, and between Resources and Characteristics: this i		system and Resources and between Resources and Characteristics: For cla
	s not shown on the		rity, this is not shown in the
	figure for clarity.</t>		figure.</t>
	<figure anchor="systemfig">		<figure anchor="systemfig">
	<name>Resources and Characteristics</name>		<name>Resources and Characteristics</name>
	<artwork align="center" name="" type="" alt="">		<artwork align="center" name="" type="" alt=""><![CDATA[
	<![CDATA[		Characteristics
	Characteristics		^
	^		|
	|		Resources
	Resources		^
	^		|
	|		Network system
	Network system		]]></artwork>
	]]>
	</artwork>
	</figure>		</figure>
	<t>The Value of a Characteristic of a Resource may change over time. Specif ic		<t>The Value of a Characteristic of a Resource may change over time. Specif ic
	Changes in Value may be noticed at a specific time (as digital Changes), Detected, and		Changes in Value may be noticed at a specific time (as digital Changes), Detected, and
	treated as Events. This is shown on the left of <xref target="characterf ig" />.</t>		treated as Events. This is shown on the left-hand side of <xref target=" characterfig" />.</t>
	<t>The center of <xref target="characterfig" /> shows how the Value of a Ch aracteristic		<t>The center of <xref target="characterfig" /> shows how the Value of a Ch aracteristic
	may change over time. The Value may be Detected at specific times or per iodically		may change over time. The Value may be Detected at specific times or per iodically
	and give rise to Conditions that are States (and consequently State Chan ges).</t>		and give rise to Conditions that are States (and consequently State Chan ges).</t>
	<t>In practice, the Characteristic may vary in an analog manner over time a s shown on the		<t>In practice, the Characteristic may vary in an analog manner over time a s shown on the
	right-hand side of <xref target="characterfig" />. The Value can be read or reported		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 deeme d Relevant Values,		(i.e., Detected) periodically leading to analog Values that may be deeme d Relevant Values,
	or may be evaluated over time as shown in <xref target="thresholdfig" />		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">		<figure anchor="characterfig">
	<name>Characteristics and Changes</name>		<name>Characteristics and Changes</name>
	<artwork align="center" name="" type="" alt="">		<artwork align="center" name="" type="" alt=""><![CDATA[
	<![CDATA[
	Event State Value		Event State Value
	Condition		Condition
	^ ^ ^		^ ^ ^
	Detect : Detect : Detect :		Detect : Detect : Detect :
	: : :		: : :
	^ ^ ^ ^ ^ /\		^ ^ ^ ^ ^ /\
	: : : : : / \		: : : : : / \
	: : : : : /\ / \		: : : : : /\ / \
	__ __ _____ / \/		__ __ _____ / \/
	| | | | /\/		| | | | /\/
	__| |__ ____| |____ /		__| |__ ____| |____ /
	Change at a time Change over time Change over time		Change at a time Change over time Change over time
	]]>		]]></artwork>
	</artwork>
	</figure>		</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 no ted above, an		<t><xref target="eventfig" /> shows the workflow progress for Events. As no ted above, an
	Event is a Change in the Value of a Characteristic at a time. The Event may be		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		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		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 Occur rence may be		it is an Occurrence and possibly to indicate a Change of State. An Occur rence may be
	undesirable (a Fault) and that can cause an Alert to be generated, may b e evidence		undesirable (a Fault) and that can cause an Alert to be generated, may b e evidence
	of a Problem and could directly indicate a Cause. In some cases, an Aler t may give		of a Problem and could directly indicate a Cause. In some cases, an Aler t may give
	rise to an Alarm highlighting the potential or actual presence of a Prob		rise to an Alarm highlighting the potential or actual presence of a Prob
	lem.</t>		lem.
			<!-- [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">		<figure anchor="eventfig">
	<name>Event and Dependent Terms</name>		<name>Event and Dependent Terms</name>
	<artwork align="center" name="" type="" alt="">		<artwork align="center" name="" type="" alt=""><![CDATA[
	<![CDATA[
	Alert - - - > Alarm		Alert - - - > Alarm
	^		^
	|		|
	| -----> Cause		| -----> Cause
	| |		| |
	|----------> Problem		|----------> Problem
	|		|
	|		|
	Fault		Fault
	^		^
	|		|
	|		|
	|		|
	Occurrence		Occurrence
	^		^
	|		|
	|----------> State		|----------> State
	|		|
	|		|
	Event		Event
	]]>		]]></artwork>
	</artwork>
	</figure>		</figure>
	<t>Parallel to the workflow for Events, <xref target="statefig" /> shows th e		<t>Parallel to the workflow for Events, <xref target="statefig" /> shows th e
	workflow progress for States. As shown in <xref target="characterfig" /> ,		workflow progress for States. As shown in <xref target="characterfig" /> ,
	Change noted at a particular time gives rise to State. The State may be		Change noted at a particular time gives rise to State. The State may be
	deemed to have Relevance considering policy, relative to a specific pers pective,		deemed to have Relevance considering policy, relative to a specific pers pective,
	with a view to intent, and in relation to other Events, States, and Valu es.		with a view to intent, and in relation to other Events, States, and Valu es.
	A Relevant State may be deemed a Problem, or may indicate a Problem or		A Relevant State may be deemed a Problem, or it may indicate a Problem o
	potential Problem.</t>		r
			potential 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		<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		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 stat e may		raised as the result of a Problem, and the transition to an Alarmed stat e may
	give rise to an Alert.</t>		give rise to an 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">		<figure anchor="statefig">
	<name>State and Dependent Terms</name>		<name>State and Dependent Terms</name>
	<artwork align="center" name="" type="" alt="">		<artwork align="center" name="" type="" alt=""><![CDATA[
	<![CDATA[
	Alarm - - -> Alert		Alarm - - -> Alert
	^		^
	| ------> Incident		| ------> Incident
	| |		| |
	| | ---> Cause		| | ---> Cause
	| | |		| | |
	Problem---------> Symptom		Problem---------> Symptom
	^		^
	|		|
	| Relevance		| Relevance
	|		|
	|		|
	State		State
	]]>		]]></artwork>
	</artwork>
	</figure>		</figure>
	<t><xref target="consolidationfig" /> shows how Faults and Problems		<t><xref target="consolidationfig" /> shows how Faults and Problems
	may be consolidated to determine the Causes. The arrows show how		may be consolidated to determine the Causes. The arrows show how
	one item may give rise to another.</t>		one item may give rise to another.</t>
	<t>A Cause can be indicated by or determined from Faults, Problems, and Sym ptoms.		<t>A Cause can be indicated by or determined from Faults, Problems, and Sym ptoms.
	It may be that one Cause points to another, and can also be considered a s a		It may be that one Cause points to another, and it can also be considere d as a
	Symptom. The determination of Causes can consider multiple inputs. An In cident		Symptom. The determination of Causes can consider multiple inputs. An In cident
	results from one or more Problems.</t>		results from one or more Problems.</t>
	<figure anchor="consolidationfig">		<figure anchor="consolidationfig">
	<name>Consolidation of Symptoms and Causes</name>		<name>Consolidation of Symptoms and Causes</name>
	<artwork align="center" name="" type="" alt="">		<artwork align="center" name="" type="" alt=""><![CDATA[
	<![CDATA[
	---------		---------
	------------- | |		------------- | |
	| ----------> | Symptom |		| ----------> | Symptom |
	| | | |		| | | |
	| | ---------		| | ---------
	v | ^		v | ^
	--------- |		--------- |
	------->| Cause |<--------- |		------->| Cause |<--------- |
	| --------- | |		| --------- | |
	| ^ | | |		| ^ | | |
	| | | | |		| | | | |
	| --- | |		| --- | |
	| | |		| | |
	--------- --------- ----------		--------- --------- ----------
	| Fault |------------------->| Problem |------->| Incident |		| Fault |------------------->| Problem |------->| Incident |
	--------- --------- ----------		--------- --------- ----------
	]]>		]]></artwork>
	</artwork>
	</figure>		</figure>
	<t><xref target="thresholdfig" /> shows		<t><xref target="thresholdfig" /> shows
	how thresholds are important in the consideration of analog Values and E vents.		how thresholds are important in the consideration of analog Values and E vents.
	The arrows in the figure show how one item may give rise to or utilize a nother.		The arrows in the figure show how one item may give rise to or utilize a nother.
	The use of threshold-driven Events and States (and the Alerts that		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 "fla pping"		they might give rise to) must be treated with caution to dampen any "fla pping"
	(so that consistent States may be observed) and to avoid overwhelming ma nagement		(so that consistent States may be observed) and to avoid overwhelming ma nagement
	processes or systems. Analog Values may be read or notified from the Res ource		processes or systems. Analog Values may be read or notified from the Res ource
	and could transition a threshold, be deemed Relevant Values, or evaluate d over		and could transition a threshold, be deemed Relevant Values, or be evalu ated over
	time. Events may be counted, and the Count may cross a threshold or		time. Events may be counted, and the Count may cross a threshold or
	reach a Relevant Value.</t>		reach a Relevant Value.</t>
	<t>The Threshold Process may be implementation-specific and subject to poli cies.		<t>The Threshold Process may be implementation specific and subject to poli cies.
	When a threshold is crossed and any other conditions are matched, an Eve nt		When a threshold is crossed and any other conditions are matched, an Eve nt
	may be determined, and treated like any other Event.</t>		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 other
			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">		<figure anchor="thresholdfig">
	<name>Counts, Thresholds, and Values</name>		<name>Counts, Thresholds, and Values</name>
	<artwork align="center" name="" type="" alt="">		<artwork align="center" name="" type="" alt=""><![CDATA[
	<![CDATA[
	Occurrence		Occurrence
	^		^
	|		|
	|---------------------> State		|---------------------> State
	|		|
	| ------- Relevance		| ------- Relevance
	|------>| Count |-----------------------------> Value		|------>| Count |-----------------------------> Value
	| ------- | ^		| ------- | ^
	| | | |		| | | |
	| | | | Relevance		| | | | Relevance
	skipping to change at line 679 ¶		skipping to change at line 1099 ¶
	| ----------- | | |		| ----------- | | |
	| | Threshold | | | |		| | Threshold | | | |
	|<----| Process |<------ | |		|<----| Process |<------ | |
	| | |<----------------------| |		| | |<----------------------| |
	| ----------- ----------------		| ----------- ----------------
	| ^		| ^
	| |		| |
	| Detect Detect |		| Detect Detect |
	| |		| |
	Change at a Time Change over Time		Change at a Time Change over Time
	]]>		]]></artwork>
	</artwork>
	</figure>		</figure>
	</section>		</section>
	<section anchor="security-considerations" numbered="true" toc="default">		<section anchor="security-considerations" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>This document specifies terminology and has no direct effect on the sec urity of		<t>This document specifies terminology and has no direct effect on the sec urity of
	implementations or deployments. However, protocol solutions and managem ent models		implementations or deployments. However, protocol solutions and managem ent models
	need to be aware of several aspects:</t>		need to be aware of several aspects:</t>
	<ul>		<ul>
	<li>		<li>
	<t>The exposure of information pertaining to Faults and Problems may m ake available knowledge		<t>The exposure of information pertaining to Faults and Problems may m ake available knowledge
	of the internal workings of a network (in particular its vulnerabil ities) that		of the internal workings of a network (in particular, its vulnerabi lities) that
	may be of use to an attacker.</t>		may be of use to an attacker.</t>
	</li>		</li>
	<li>		<li>
	<t>Systems that generate management information (messages, notificatio ns, etc.) when		<t>Systems that generate management information (messages, notificatio ns, etc.) when
	Faults occur, may be attacked by causing them to generate so much i nformation		Faults occur may be attacked by causing them to generate so much in formation
	that the system that manages the network is swamped and unable to p roperly manage		that the system that manages the network is swamped and unable to p roperly manage
	the network.</t>		the network.</t>
	</li>		</li>
	<li>		<li>
	<t>Reporting false information about Faults (or masking reports of Fau lts) may		<t>Reporting false information about Faults (or masking reports of Fau lts) may
	cause the system that manages the network to function incorrectly.< /t>		cause the system that manages the network to function incorrectly.< /t>
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	skipping to change at line 722 ¶		skipping to change at line 1141 ¶
	<section anchor="privacy-considerations" numbered="true" toc="default">		<section anchor="privacy-considerations" numbered="true" toc="default">
	<name>Privacy Considerations</name>		<name>Privacy Considerations</name>
	<t>Network fault and problem management should preserve user privacy by		<t>Network fault and problem management should preserve user privacy by
	not exposing user data or information about end-user activities.</t>		not exposing user data or information about end-user activities.</t>
	<t>Network Telemetry involves observing network traffic and collecting		<t>Network Telemetry involves observing network traffic and collecting
	operational data from the network, while Network Monitoring is the		operational data from the network, while Network Monitoring is the
	process of keeping records of data gathered in Network Telemetry.		process of keeping records of data gathered in Network Telemetry.
	Therefore, it is possible that the data observed and collected		Therefore, it is possible that the data observed and collected
	includes users&apos; privacy information. Such information must be		includes users' privacy information. Such information must be
	protected and controlled to avoid exposure to unauthorised parties.		protected and controlled to avoid exposure to unauthorized parties.
	Particular care may need to be exercised over stores of such		Particular care may need to be exercised over stores of such
	information which might be accessed at any time (including far into		information that might be accessed at any time (including far into
	the future).</t>		the future).
			</t>
	<t>Additionally, a network operator will be concerned to keep control of		<t>Additionally, a network operator will be concerned about keeping contro l of
	all information about Faults to protect their own privacy and the		all information about Faults to protect their own privacy and the
	details of how they operate their network.</t>		details of how they operate their network.</t>
	</section>		</section>
	<section anchor="iana-considerations" numbered="true" toc="default">		<section anchor="iana-considerations" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document makes no requests for IANA action.</t>		<t>This document has no IANA actions.</t>
	</section>
	<section anchor="acknowledgments" numbered="false" toc="default">
	<name>Acknowledgments</name>
	<t>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 O
	rman, Stewart Bryant, Bo Wu, Paul Kyzivat,
	Jouni Korhonen, Reshad Rahman, Rob Wilton, Mahesh Jethanandani, Tim Bra
	y, Paul Aitken, and Deb Cooley for their helpful comments.</t>
	<t>Special thanks to the team that met at a side meeting at IETF-120 to di
	scuss 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>
	</ul>
	</section>		</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="I-D.ietf-nmop-network-anomaly-architecture" to="Net-An
			omaly-Arch"/>
			<displayreference target="I-D.ietf-nmop-network-incident-yang" to="Net-Incident-
			Mgmt-YANG"/>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	&RFC3877;		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.387
	&RFC6632;		7.xml"/>
	&RFC8342;		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.663
	&RFC8632;		2.xml"/>
	&RFC9232;		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.834
	&RFC9315;		2.xml"/>
	&RFC9417;		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.863
			2.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.923
			2.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.931
			5.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.941
			7.xml"/>
	&I-D.ietf-nmop-network-anomaly-architecture;		<!-- draft-ietf-nmop-network-anomaly-architecture (I-D Exists)
	&I-D.ietf-nmop-network-incident-yang;		(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-arch
			itecture-06" />
			</reference>
			<!-- draft-ietf-nmop-network-incident-yang (I-D Exists) -->
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ie
			tf-nmop-network-incident-yang.xml"/>
	</references>		</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 helpful comments. -->
			</t>
			<t>Special thanks to the team that met at a side meeting at IETF 120 to
			discuss some of the thorny issues:</t>
			<ul spacing="compact">
			<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>
	</back>		</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>		</rfc>
End of changes. 80 change blocks.
	354 lines changed or deleted		784 lines changed or added
This html diff was produced by rfcdiff 1.48.