Internet Engineering Task Force (IETF) N. Davis, Ed.
Request for Comments: 9940 Ciena
Category: Informational A. Farrel, Ed.
ISSN: 2070-1721 Old Dog Consulting
T. Graf
Swisscom
Q. Wu
C. Yu
Huawei
April 2026
This document sets out some terms that are fundamental to a common understanding of network fault and problem management within the IETF.
この文書では、IETF 内でのネットワーク障害および問題管理の共通理解の基礎となるいくつかの用語を説明します。
The purpose of this document is to bring clarity to discussions and other work related to network fault and problem management -- in particular, to YANG data models and management protocols that report, make visible, or manage network faults and problems.
この文書の目的は、ネットワーク障害と問題の管理に関連する議論とその他の作業、特にネットワーク障害と問題を報告、可視化、または管理する YANG データ モデルと管理プロトコルを明確にすることです。
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書は Internet Standards Track 仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (IESG) によって公開が承認されています。IESG によって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではありません。RFC 7841 のセクション 2 を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9940.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9940 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
2. Usage of Terms
3. Terminology
3.1. Context Terminology
3.2. Core Terms
3.3. Other Terms
4. Workflow Explanations
5. Security Considerations
6. Privacy Considerations
7. IANA Considerations
8. Informative References
Acknowledgments
Authors' Addresses
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 [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 the network's ability to forward traffic according to expected behaviors that may reduce the network's ability to deliver services. Such events may also impact the ability to control and operate the network. The document also considers 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 network behavior.
大規模ネットワークの運用を成功させるには、効果的なネットワーク管理が必要です。これには、ネットワーク制御、ネットワーク可観測性、ネットワーク分析、ネットワーク保証、そしてネットワーク制御に戻るという好循環が必要です。ネットワーク障害および問題管理 [RFC6632] は、ネットワーク管理および制御ソリューションの重要な側面です。ネットワーク内のイベントの検出、レポート、検査、分離、相関、および管理を扱います。このドキュメントの目的は、ネットワークのサービス提供能力を低下させる可能性がある、予想される動作に従ってトラフィックを転送するネットワークの能力に悪影響を与えるイベントに焦点を当てることです。このようなイベントは、ネットワークの制御と運用の能力にも影響を与える可能性があります。この文書では、提供されるサービスの品質や信頼性を低下させるその他の障害についても考慮しています。障害および問題の管理の概念には、問題の原因を特定し、予想されるネットワーク動作の回復に向けて実行するアクションが含まれます。
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 terminology be used so that there is a clear understanding of how the elements of the management and control solutions fit together and how faults and problems will be handled.
IETF 内の多くの作業では、YANG データ モデルや管理プロトコルなどの障害管理システムのコンポーネントを提供することが求められています。管理および制御ソリューションの要素がどのように組み合わされ、障害や問題がどのように処理されるかを明確に理解できるように、共通の用語を使用することが重要です。
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 and below; hence, this document is specifically about "network fault and problem 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.
この文書では、ネットワークの障害と問題の管理を共通に理解するための基本となるいくつかの用語を説明します。「障害」と「問題」はインターネットのあらゆるレベルのテクノロジーに適用される概念ですが、この文書の範囲はネットワーク層以下に限定されます。したがって、この文書は特に「ネットワーク障害と問題の管理」について説明します。このドキュメントでは、「インシデント」の概念についても触れています。インシデントとは、1 つ以上の問題から生じ、ネットワーク サービスが中断されることです。
Note that some useful terms are defined in [RFC3877] and [RFC8632]. The definitions in this document are informed by those documents, but they are not dependent on that prior work.
いくつかの有用な用語が [RFC3877] および [RFC8632] で定義されていることに注意してください。この文書の定義はそれらの文書に基づいていますが、以前の研究には依存しません。
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, but care 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.
この文書で定義されている用語は、IETF 内でネットワーク障害および問題管理の範囲で一貫して使用されることを目的としています。同様の概念が他の本文で説明されている場合、それらの他の説明と調和する試みが行われていますが、用語が本文間で一貫して使用されていない場合や、用語がネットワーク層の外側で適用されている場合には注意が必要です。他の団体がこの文書で定義されている用語が役立つと判断した場合は、自由に使用できます。
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.
この文書の目的は、他の文書で使用される以下の用語を定義することです。他の用語は、これらの定義を可能にするために定義されており、他の文書でも使用される場合がありますが、それはここでの定義の主な目的ではありません。
* Event
* イベント
* State
* 州
* Fault
* 故障
* Problem
* 問題
* Symptom
* 症状
* Cause
* 原因
* Alert
* アラート
* Alarm
* アラーム
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 include an early section listing the terms inherited from this document with a citation.
他の文書がこの文書で定義されている用語を使用する場合、口語的な使用と区別しやすくするために、この文書のように用語を大文字で使用する必要があり、この文書から継承した用語を引用とともにリストする最初のセクションを含めるべきであることが、ここで提案されています。
This section contains key terms. It is split into three subsections.
このセクションには重要な用語が含まれています。3 つのサブセクションに分かれています。
* Section 3.1 contains terms that help set the context for network fault and problem management systems.
* セクション 3.1 には、ネットワーク障害および問題管理システムのコンテキストを設定するのに役立つ用語が含まれています。
* Section 3.2 includes specific and detailed core terms that will be used in other documents that describe elements of the network fault and problem management systems.
* セクション 3.2 には、ネットワーク障害および問題管理システムの要素を説明する他の文書で使用される、特定かつ詳細な中心用語が含まれています。
* Section 3.3 provides three further terms that may be helpful.
* セクション 3.3 では、さらに役立つ 3 つの用語を説明します。
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.
このセクションには、この作業の残りの部分のコンテキストを説明するのに役立ついくつかの用語が含まれています。この用語は、ネットワーク テレメトリから始まり、ネットワーク オブザーバビリティに至るまでの、カスケードされた一連のプロセスと見なすことができます。定義は意図的に比較的簡潔に保たれています。さらなる文書では、具体性を失うことなくこれらの用語を拡張する可能性があります。そのような文脈化（ある場合）は、それらの文書内で明確に強調表示される必要があります。
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]).
これは [RFC9232] で定義されており、派生元のネットワーク プレーン (レイヤ 3、レイヤ 2、レイヤ 1 など) に従って分類された運用ネットワーク データを収集するプロセスについて説明します。ネットワーク テレメトリ プロセスを通じて収集されたデータには、サービス定義 (つまり、[RFC9315] のセクション 3.1 に基づく「インテント」) に関連するデータは含まれません。
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 behavior. This approach differentiates Network Monitoring from resource or device monitoring, which focuses on individual resources or components (Section 3.2).
これは、ネットワーク トポロジに関連する機能の継続的な記録を保持するプロセスです。これには、トラフィック パターン、デバイスの健全性、パフォーマンス メトリック、ネットワーク全体の動作などのさまざまな側面の追跡が含まれます。このアプローチは、ネットワーク監視を、個々のリソースまたはコンポーネントに焦点を当てたリソースまたはデバイス監視とは区別します (セクション 3.2)。
Network Analytics:
ネットワーク分析:
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 operational data -- for example, a symptom.
これは、運用ネットワーク データから分析的な洞察を導き出すプロセスです。プロセスは、運用データを分析し、その運用データに関連する新しい分析データ (症状など) を出力するソフトウェア、システム、または人間によって実行される可能性があります。
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 identifying anomalies and their causes. Network Observability begins with information gathered using Network Monitoring tools. That information 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 network.
これは、ネットワーク動作の兆候を検出し、異常とその原因を特定することを目的として、観察された運用ネットワーク データ (ログ、アラーム、トレースなど) の分析を通じてネットワーク動作の評価を可能にするプロセスです。ネットワークの可観測性は、ネットワーク監視ツールを使用して収集された情報から始まります。その情報は、他の運用データによってさらに強化される可能性があります。可観測性プロセスの期待される結果は、ネットワークの期待される状態に対する観察された状態の偏差の特定と分析です。
Thus, there is a cascaded sequence where the following relationships apply:
したがって、次の関係が適用されるカスケード シーケンスが存在します。
* Network Telemetry is the process of collecting operational data from a network.
* ネットワーク テレメトリは、ネットワークから運用データを収集するプロセスです。
* Network Monitoring is the process of creating/keeping a record of data gathered in Network Telemetry.
* ネットワーク監視は、ネットワーク テレメトリで収集されたデータの記録を作成/保持するプロセスです。
* Network Analytics is the process of deriving insight through the data recorded in Network Monitoring.
* ネットワーク分析は、ネットワーク監視に記録されたデータを通じて洞察を得るプロセスです。
* Network Observability is the process of enabling behavioral assessment of a network through Network Analytics.
* ネットワークの可観測性は、ネットワーク分析を通じてネットワークの動作評価を可能にするプロセスです。
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 explanations in Section 4 may aid understanding the terms set out here.
このセクションの用語は、上から下に読んでも理解できるような順序で記載されています。セクション 4 の図と説明は、ここで説明する用語を理解するのに役立ちます。
Resource:
リソース：
A Resource is 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).
* リソースは再帰的な概念であるため、リソースは他のリソースの集合である場合があります (たとえば、ネットワーク ノードはネットワーク インターフェイスの集合で構成されます)。
Characteristic:
特性：
A Characteristic is an observable or measurable aspect or behavior associated with a Resource.
特性とは、リソースに関連付けられた観察可能または測定可能な側面または動作です。
* A Characteristic may be considered to be built on facts (see "Value", below) and the contexts and descriptors that identify and give meaning to the facts.
* 特性は、事実 (以下の「値」を参照) と、事実を識別して意味を与えるコンテキストおよび記述子に基づいて構築されていると考えることができます。
* The term "Metric" (see "metric" in [RFC9417]) is another word for a measurable Characteristic, which may also be thought of as analogous to a "variable".
* 「メトリック」という用語 ([RFC9417] の「メトリック」を参照) は、測定可能な特性を表す別の言葉であり、「変数」に類似したものと考えることもできます。
Value:
値：
A Value is a measure of a Characteristic associated with a Resource. It may be in the form of a categorization (e.g., high or low), an integer (e.g., a count or gauge), or a reading of a continuous variable (e.g., an analog measurement), etc.
値は、リソースに関連付けられた特性の尺度です。それは、分類 (例: 高または低)、整数 (例: カウントまたはゲージ)、または連続変数の読み取り値 (例: アナログ測定) などの形式である場合があります。
Change:
変化：
In the context of Network Monitoring, a Change is the variation in the Value of a Characteristic associated with a Resource. A Change may arise over a period of time.
ネットワーク監視のコンテキストでは、変更はリソースに関連付けられた特性の値の変化です。一定期間の経過とともに変化が生じる可能性があります。
* Not all Changes are noteworthy (i.e., they do not have Relevance).
* すべての変更が注目に値するわけではありません (つまり、関連性がありません)。
* Perception of Change depends upon Detection, the sampling rate/accuracy/detail, and perspective.
* 変化の認識は、検出、サンプリング レート/精度/詳細、および視点によって異なります。
* It may be helpful to qualify this as "Value Change" because the English word "change" is often heavily used.
* 英語の「変化」という単語は頻繁に使用されるため、これを「価値の変化」と呼ぶとよいでしょう。
Event:
イベント：
An Event is the variation in Value of a Characteristic of a Resource at a distinct moment in time (i.e., the period is negligible).
イベントは、特定の瞬間におけるリソースの特性の値の変動です (つまり、期間は無視できます)。
* Compared with a Change, which may be over a period of time, an Event happens at a distinct moment in time. Thus, an Event may be the observation of a Change.
* 一定期間にわたる変化と比較して、イベントは明確な瞬間に発生します。したがって、イベントは変化の観察である可能性があります。
Condition:
状態：
A Condition is an interpretation of the Values of a set of one or more Characteristics of a Resource (with respect to working order or some other aspect relevant to the Resource purpose/application) -- for example, "low available memory". Thus, it is the output of a function applied to a set of one or more variables.
条件は、リソースの 1 つ以上の特性のセットの値の解釈です (作業順序、またはリソースの目的/アプリケーションに関連するその他の側面に関して) (たとえば、「使用可能なメモリが少ない」など)。したがって、これは 1 つ以上の変数のセットに適用される関数の出力です。
State:
州：
A State is a particular Condition that a Resource has (i.e., it is in a State) at a specific time. For example, a router may report the total amount of memory it has and how much is free. These are the Values of two Characteristics of a Resource. These Values can be interpreted to determine the Condition of the Resource, and that may determine the State of the router, such as shortage of memory.
状態とは、特定の時点でリソースが持つ特定の条件です (つまり、リソースはある状態にあります)。たとえば、ルータは、そのメモリの総量と空きメモリの量を報告する場合があります。これらは、リソースの 2 つの特性の値です。これらの値はリソースの状態を判断するために解釈でき、それによってメモリ不足などのルーターの状態が判断される場合があります。
* While a State may be observed at a specific moment in time, it is actually determined by summarizing measurement over time in a process sometimes called State compression.
* 状態は特定の瞬間に観察される可能性がありますが、実際には、状態圧縮と呼ばれることもあるプロセスでの経時的な測定を要約することによって決定されます。
* It may be helpful to qualify this as "Resource State" to make clear the distinction between this and other uses of "state" such as "protocol state".
* これを「リソース状態」と修飾して、「プロトコル状態」などの「状態」の他の使用法との区別を明確にすることが役立つ場合があります。
* This term may be contrasted with "operational state" as used in [RFC8342]. For example, the state of a link might be up/down/ degraded, but the operational state of the link would include a collection of Values of Characteristics of the link.
* この用語は、[RFC8342] で使用される「動作状態」と対比される場合があります。たとえば、リンクの状態はアップ/ダウン/劣化の可能性がありますが、リンクの動作状態にはリンクの特性値のコレクションが含まれます。
Detect (hence Detected, Detection):
検出 (したがって、検出されました、検出):
To Detect is to notice the presence of something (State, Change, Event, activity, etc.)
検出とは、何か (状態、変化、イベント、アクティビティなど) の存在に気づくことです。
* Also to notice a Change (from the perspective of an observer such as a monitoring system).
* (監視システムなどの観察者の観点から) 変化に気づくためでもあります。
Relevance:
関連性:
Relevance is the consideration of an Event, State, or Value (through the application of policy, relative to a specific perspective or intent, and in relation to other Events, States, and Values) to determine whether it is of note to the system that controls or manages the network. Note, for example, that not all Changes are Relevant.
関連性とは、イベント、状態、または値を (ポリシーの適用を通じて、特定の観点または意図に関連して、また他のイベント、状態、および値との関連で) 考慮して、それがネットワークを制御または管理するシステムにとって重要であるかどうかを判断することです。たとえば、すべての変更が関連するわけではないことに注意してください。
* This term may also be used as "Relevant Event", "Relevant State", or "Relevant Value".
* この用語は、「関連イベント」、「関連状態」、「関連値」としても使用されます。
Occurrence:
発生：
An Occurrence is a Relevant Event or a particular Relevant Change.
発生とは、関連するイベントまたは特定の関連する変更です。
* An Occurrence may be an aggregation or abstraction of multiple fine-grained Events or Changes.
* 発生は、複数のきめの細かいイベントまたは変更の集約または抽象化である場合があります。
* An Occurrence may occur at any macro or micro scale because Resources are a recursive concept. An Occurrence may be perceived, depending on the scope of observation (i.e., according to the level of Resource recursion that is examined). That is, Occurrences, themselves, are a recursive concept.
* リソースは再帰的な概念であるため、オカレンスはマクロまたはミクロのスケールで発生する可能性があります。発生は、観察の範囲に応じて (つまり、検査されるリソースの再帰のレベルに応じて) 認識される場合があります。つまり、オカレンス自体は再帰的な概念です。
Fault:
故障：
A Fault is an Occurrence (i.e., an Event or a Change) that is not desired/required (as it may be indicative of a current or future undesired State). Thus, a Fault happens at a moment in time. A Fault can potentially be associated with a Cause. See [RFC8632] for a more detailed discussion of network faults.
障害とは、望ましくない/必要ではない発生 (つまり、イベントまたは変化) です (現在または将来の望ましくない状態を示している可能性があるため)。したがって、フォルトはある瞬間に発生します。障害は原因に関連付けられている可能性があります。ネットワーク障害の詳細については、[RFC8632] を参照してください。
* 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.
* 障害と問題の間にはコンテキストに応じた区別があることに注意してください。たとえば、冗長性が存在する接続サービスでは、リンクのダウンは問題ですが、ネットワーク リソースの管理の観点からは、リンクのダウンは障害です。同様に、たとえば、2 つの電源装置を備えたルータで、バックアップ電源装置に障害が発生し、プライマリ電源装置が保護されない場合、これは問題となります。
Problem:
問題：
A Problem is a State that is undesirable and that may require remedial action. A Problem cannot necessarily be associated with a Cause. The resolution of a Problem does not necessarily act on the thing that has the Problem.
問題とは、望ましくない状態であり、是正措置が必要となる可能性がある状態です。問題は必ずしも原因と関連付けられるとは限りません。問題の解決は、必ずしも問題を抱えているものに作用するとは限りません。
* Note that there is a historic aspect to the concept of a Problem. The current State may be operational, but there could have been a Fault that is unexplained, and the fact of that unexplained recent Fault is a Problem.
* 問題の概念には歴史的な側面があることに注意してください。現在の状態は動作している可能性がありますが、説明のつかない障害が発生している可能性があり、その説明のつかない最近の障害の事実が問題です。
* Note that while a Problem is unresolved it may continue to require attention. A record of resolved Problems may be maintained in a log.
* 問題が解決されていない間も、引き続き注意が必要になる可能性があることに注意してください。解決された問題の記録はログに保存される場合があります。
* Note that there may be a State that is considered to be a Problem from several perspectives. For example, consider a "loss of light" State that may cause multiple services to fail. In this example, a new State (the light recovers) may cause the Problem to be resolved from one perspective (the services are operational once more) but may leave the Problem as unresolved (because the loss of light has not been explained). Further, in this example, there could be another development (the reason for the temporary loss of light is traced to a microbend in the fiber that is repaired) resulting in that unresolved Problem now being resolved. But, in this example, this still leaves a further Problem unresolved (a microbend occurred, and that Problem is not resolved until it is understood how it occurred and a remedy is put in place to prevent recurrence).
* いくつかの観点から問題とみなされる状態が存在する可能性があることに注意してください。たとえば、複数のサービスの障害を引き起こす可能性がある「光の損失」状態を考えてみましょう。この例では、新しい状態 (光が回復する) によって、ある観点からは問題が解決される (サービスが再び動作する) 可能性がありますが、(光の損失が説明されていないため) 問題が未解決のままになる可能性があります。さらに、この例では、未解決の問題が解決される別の展開（光の一時的な損失の理由は、修復されたファイバーのマイクロベンドに起因すると考えられます）が発生する可能性があります。しかし、この例では、さらなる問題が未解決のまま残されています（マイクロベンドが発生しましたが、その問題は、どのように発生したのかが理解され、再発を防ぐための対策が講じられるまで解決されません）。
Cause:
原因：
A Cause is the Events (Detected or otherwise) that gave rise to a Fault/Problem.
原因とは、障害/問題を引き起こしたイベント (検出されたかどうかに関係なく) です。
Incident:
事件：
Also referred to as "Network Incident". An Incident is an undesired Occurrence such as an unexpected interruption of a network service, degradation of the quality of a network service, or the below-target performance of a network service. An Incident results from one or more Problems, and a Problem may give rise to or contribute to one or more Incidents. Greater discussion of Network Incident relationships, including Customer Incidents and Incident management, can be found in [Net-Incident-Mgmt-YANG].
「ネットワークインシデント」とも呼ばれます。インシデントとは、ネットワーク サービスの予期しない中断、ネットワーク サービスの品質の低下、ネットワーク サービスのパフォーマンスが目標を下回るなど、望ましくない出来事です。インシデントは 1 つ以上の問題から生じ、問題は 1 つ以上のインシデントを引き起こしたり、インシデントに影響を与えたりする場合があります。顧客インシデントやインシデント管理を含む、ネットワーク インシデントの関係についての詳しい説明は、[Net-Incident-Mgmt-YANG] でご覧いただけます。
Symptom:
症状：
A Symptom is an observable Value, Change, State, Event, or Condition considered as an indication of a Problem or potential Problem.
症状は、問題または潜在的な問題の兆候とみなされる、観察可能な値、変化、状態、イベント、または状態です。
Anomaly:
異常:
Also referred to as "Network Anomaly". An Anomaly is an unusual or unexpected Event or pattern in network data in the forwarding plane, control plane, or management plane that deviates from the normal, expected behavior. See [Net-Anomaly-Arch] for more details.
「ネットワーク異常」とも呼ばれます。異常とは、フォワーディング プレーン、コントロール プレーン、または管理プレーンのネットワーク データにおける、通常の予期される動作から逸脱した異常または予期しないイベントまたはパターンです。詳細については、「Net-Anomaly-Arch」を参照してください。
Alert:
警告:
An Alert is an indication of a Fault.
アラートは障害の兆候です。
Alarm:
アラーム：
As specified in [RFC8632], an Alarm signifies an undesirable State in a Resource that requires corrective action. From a management point of view, an Alarm can be seen as a State in its own right and the transition to this State may result in an Alert being issued. The receipt of this Alert may give rise to a continuous indication (to a human operator) highlighting the potential or actual presence of a Problem.
[RFC8632] で規定されているように、アラームは、是正措置が必要なリソース内の望ましくない状態を示します。管理の観点からは、アラームはそれ自体が状態であると見なされ、この状態への移行によりアラートが発行される可能性があります。このアラートを受信すると、問題の潜在的または実際の存在を強調する継続的な表示が (人間のオペレーターに対して) 生じる可能性があります。
Three other terms may be helpful:
他に次の 3 つの用語が役に立つかもしれません。
Intermittent:
間欠：
A State that is not continuous but that keeps recurring in some time frame.
連続的ではないが、一定の時間枠で繰り返し起こる状態。
Transient:
トランジェント:
A State that is not continuous and that occurs once in some time frame.
継続的ではなく、ある時間枠に一度発生する状態。
Recurrent:
繰り返し発生する:
A Problem that is actively resolved but returns.
積極的に解決されたものの、再発した問題。
This section aims to add information about the relationship between the terms defined in Section 3.2 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.
このセクションは、ネットワーク障害および問題管理の文脈におけるセクション 3.2 で定義された用語間の関係についての情報を追加することを目的としています。ここでの文章と図は説明を目的としたものであり、用語の定義を規範するものではありません。
The relationship between Resources and Characteristics is shown in Figure 1. Note that there is a 1:n relationship between a Network system and Resources and between Resources and Characteristics: For clarity, this is not shown in the figure.
リソースと特性の関係を図 1 に示します。ネットワーク システムとリソース、およびリソースと特性の間には 1:n の関係があることに注意してください。わかりやすくするために、これは図には示されていません。
Characteristics
^
|
Resources
^
|
Network system
Figure 1: Resources and Characteristics
図 1: リソースと特性
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 the left-hand side of Figure 2.
リソースの特性の値は時間の経過とともに変化する可能性があります。値の特定の変化は、特定の時間に (デジタル変化として) 認識され、検出され、イベントとして扱われる場合があります。これを図 2 の左側に示します。
The center of Figure 2 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).
図 2 の中央は、特性の値が時間の経過とともにどのように変化するかを示しています。値は特定の時間または定期的に検出され、状態である条件 (および結果として状態変化) を引き起こす可能性があります。
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 6.
実際には、図 2 の右側に示すように、特性は時間の経過とともにアナログ的に変化する可能性があります。値は定期的に読み取られるか報告される (つまり、検出される) ことで、関連する値と見なされるアナログ値が得られます。または、図 6 に示すように、時間の経過とともに評価されることもあります。
Event State Value
Condition
^ ^ ^
Detect : Detect : Detect :
: : :
^ ^ ^ ^ ^ /\
: : : : : / \
: : : : : /\ / \
__ __ _____ / \/
| | | | /\/
__| |__ ____| |____ /
Change at a time Change over time Change over time
Figure 2: Characteristics and Changes
図2：特徴と変化
Figure 3 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), which might cause an Alert to be generated. Or, an Occurrence 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 a Problem.
図 3 は、イベントのワークフローの進行状況を示しています。上で述べたように、イベントとは、一度に行われる特性の値の変化です。イベントは、それが出来事であるかどうか、場合によっては状態の変化を示すかどうかを判断するために (ポリシーを考慮して、特定の観点に関連して、意図を考慮して、および他のイベント、状態、および値に関連して) 評価される場合があります。発生は望ましくないもの (障害) である可能性があり、それによりアラートが生成される可能性があります。あるいは、発生は問題の証拠であり、原因を直接示している可能性があります。場合によっては、アラートによって、問題の潜在的または実際の存在を強調するアラームが発生することがあります。
Alert - - - > Alarm
^
|
| -----> Cause
| |
|----------> Problem
|
|
Fault
^
|
|
|
Occurrence
^
|
|----------> State
|
|
Event
Figure 3: Event and Dependent Terms
図 3: イベントと従属項
Parallel to the workflow for Events, Figure 4 shows the workflow progress for States. As shown in Figure 2, 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 potential Problem.
図 4 は、イベントのワークフローと並行して、状態のワークフローの進行状況を示しています。図 2 に示すように、特定の時点で注目された変化は状態を生じます。国家は、特定の観点に関連して、意図を考慮して、また他の出来事、国家、および価値観との関連で、政策を考慮すると関連性があるとみなされる場合があります。関連する状態は問題とみなされたり、問題または潜在的な問題を示したりする場合があります。
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 an Alert.
問題は症状に基づいて考慮され、直接的または間接的に原因にマッピングされる場合があります。インシデントは 1 つ以上の問題から発生します。問題の結果としてアラームが発生する場合があり、アラーム状態への移行によってアラートが発生する場合があります。
Alarm - - -> Alert
^
| ------> Incident
| |
| | ---> Cause
| | |
Problem---------> Symptom
^
|
| Relevance
|
|
State
Figure 4: State and Dependent Terms
図 4: 州および従属用語
Figure 5 shows how Faults and Problems may be consolidated to determine the Causes. The arrows show how one item may give rise to another.
図 5 は、障害と問題を統合して原因を特定する方法を示しています。矢印は、ある項目がどのように別の項目を生み出すかを示しています。
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.
原因は、障害、問題、症状によって示されるか、それらから判断できます。ある原因が別の原因を示している可能性もあり、それが症状であると考えることもできます。原因の決定では、複数の入力を考慮することができます。インシデントは 1 つ以上の問題から発生します。
---------
------------- | |
| ----------> | Symptom |
| | | |
| | ---------
v | ^
--------- |
------->| Cause |<--------- |
| --------- | |
| ^ | | |
| | | | |
| --- | |
| | |
--------- --------- ----------
| Fault |------------------->| Problem |------->| Incident |
--------- --------- ----------
Figure 5: Consolidation of Symptoms and Causes
図 5: 症状と原因の統合
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 be evaluated over time. Events may be counted, and the Count may cross a threshold or reach a Relevant Value.
図 6 は、アナログ値とイベントを考慮する際にしきい値がどのように重要であるかを示しています。図内の矢印は、ある項目が別の項目をどのように生成または利用するかを示しています。しきい値駆動のイベントと状態 (およびそれらが引き起こす可能性のあるアラート) の使用は、「羽ばたき」を抑制し (一貫した状態が観察されるように)、管理プロセスやシステムに負担をかけないように注意して扱う必要があります。アナログ値は、リソースから読み取られるか通知される可能性があり、しきい値を移行したり、関連値とみなされたり、時間の経過とともに評価されたりする可能性があります。イベントがカウントされる場合があり、そのカウントがしきい値を超えたり、関連値に達したりする場合があります。
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.
しきい値プロセスは実装固有であり、ポリシーの対象となる場合があります。しきい値を超え、他の条件が一致すると、イベントが決定され、他のイベントと同様に処理されます。
Occurrence
^
|
|---------------------> State
|
| ------- Relevance
|------>| Count |-----------------------------> Value
| ------- | ^
| | | |
| | | | Relevance
| | v |
| | ----------- ----------------
Event | | Evaluated | | |
^ | | over time |<--------| Analog Value |
| v ----------- | |
| ----------- | | |
| | Threshold | | | |
|<----| Process |<------ | |
| | |<----------------------| |
| ----------- ----------------
| ^
| |
| Detect Detect |
| |
Change at a Time Change over Time
Figure 6: Counts, Thresholds, and Values
図 6: カウント、しきい値、および値
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:
このドキュメントは用語を指定するものであり、実装や展開のセキュリティには直接影響しません。ただし、プロトコル ソリューションと管理モデルでは、次のいくつかの側面を認識する必要があります。
* The exposure of information pertaining to Faults and Problems may make available knowledge of the internal workings of a network (in particular, its vulnerabilities) that may be of use to an attacker.
* 障害と問題に関する情報が公開されると、ネットワークの内部動作 (特にその脆弱性) に関する情報が入手可能になり、攻撃者に利用される可能性があります。
* Systems that generate management information (messages, notifications, etc.) when Faults 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.
* 障害発生時に管理情報（メッセージ、通知など）を生成するシステムは、ネットワークを管理するシステムが混乱し、ネットワークを適切に管理できなくなるほど大量の情報を生成させる攻撃を受ける可能性があります。
* Reporting false information about Faults (or masking reports of Faults) may cause the system that manages the network to function incorrectly.
* 障害に関する虚偽の情報を報告する (または障害の報告をマスキングする) と、ネットワークを管理するシステムが誤って機能する可能性があります。
Network fault and problem management should preserve user privacy by not exposing user data or information about end-user activities.
ネットワークの障害と問題の管理では、ユーザー データやエンドユーザーのアクティビティに関する情報を公開しないようにして、ユーザーのプライバシーを保護する必要があります。
Network Telemetry involves observing network traffic and collecting operational data from the network, while Network Monitoring is the process of keeping records of data gathered in Network Telemetry. Therefore, it is possible that the data observed and collected includes users' privacy information. Such information must be protected and controlled to avoid exposure to unauthorized parties. Particular care may need to be exercised over stores of such information that might be accessed at any time (including far into the future).
ネットワーク テレメトリには、ネットワーク トラフィックの監視とネットワークからの運用データの収集が含まれます。一方、ネットワーク モニタリングには、ネットワーク テレメトリで収集されたデータの記録を保存するプロセスがあります。したがって、観察および収集されたデータにはユーザーのプライバシー情報が含まれる可能性があります。このような情報は、権限のない者への暴露を避けるために保護および管理する必要があります。いつでも (遠い将来も含めて) アクセスされる可能性があるそのような情報の保存には特に注意が必要な場合があります。
Additionally, a network operator will be concerned about keeping control of all information about Faults to protect their own privacy and the details of how they operate their network.
さらに、ネットワーク オペレータは、自身のプライバシーとネットワーク運用方法の詳細を保護するために、障害に関するすべての情報を管理し続けることを懸念します。
This document has no IANA actions.
この文書には IANA のアクションはありません。
[Net-Anomaly-Arch]
Graf, T., Du, W., Francois, P., and A. Huang Feng, "A
Framework for a Network Anomaly Detection Architecture",
Work in Progress, Internet-Draft, draft-ietf-nmop-network-
anomaly-architecture-06, 21 November 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
network-anomaly-architecture-06>.
[Net-Incident-Mgmt-YANG]
Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng,
"A YANG Data Model for Network Incident Management", Work
in Progress, Internet-Draft, draft-ietf-nmop-network-
incident-yang-08, 13 February 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
network-incident-yang-08>.
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management
Information Base (MIB)", RFC 3877, DOI 10.17487/RFC3877,
September 2004, <https://www.rfc-editor.org/info/rfc3877>.
[RFC6632] Ersue, M., Ed. and B. Claise, "An Overview of the IETF
Network Management Standards", RFC 6632,
DOI 10.17487/RFC6632, June 2012,
<https://www.rfc-editor.org/info/rfc6632>.
[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K.,
and R. Wilton, "Network Management Datastore Architecture
(NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018,
<https://www.rfc-editor.org/info/rfc8342>.
[RFC8632] Vallin, S. and M. Bjorklund, "A YANG Data Model for Alarm
Management", RFC 8632, DOI 10.17487/RFC8632, September
2019, <https://www.rfc-editor.org/info/rfc8632>.
[RFC9232] Song, H., Qin, F., Martinez-Julia, P., Ciavaglia, L., and
A. Wang, "Network Telemetry Framework", RFC 9232,
DOI 10.17487/RFC9232, May 2022,
<https://www.rfc-editor.org/info/rfc9232>.
[RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
Tantsura, "Intent-Based Networking - Concepts and
Definitions", RFC 9315, DOI 10.17487/RFC9315, October
2022, <https://www.rfc-editor.org/info/rfc9315>.
[RFC9417] Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T.
Arumugam, "Service Assurance for Intent-Based Networking
Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023,
<https://www.rfc-editor.org/info/rfc9417>.
The authors would like to thank Med Boucadair, Wanting Du, Joe Clarke, Javier Antich, Benoit Claise, Christopher Janz, Sherif Mostafa, Kristian Larsson, Dirk Von Hugo, Carsten Bormann, Hilarie Orman, Stewart Bryant, Bo Wu, Paul Kyzivat, Jouni Korhonen, Reshad Rahman, Rob Wilton, Mahesh Jethanandani, Tim Bray, Paul Aitken, and Deb Cooley for their helpful comments.
著者らは、Med Boucadair、Wanting Du、Joe Clarke、Javier Antich、Benoit Claise、Christopher Janz、Sherif Mostafa、Kristian Larsson、Dirk Von Hugo、Carsten Bormann、Hilary Orman、Stewart Bryant、Bo Wu、Paul Kyzivat、Jouni Korhonen、Reshad Rahman、Rob Wilton、Mahesh Jethanandani、に感謝します。Tim Bray、Paul Aitken、Deb Cooley に有益なコメントをいただきました。
Special thanks to the team that met at a side meeting at IETF 120 to discuss some of the thorny issues:
IETF 120 のサイドミーティングでいくつかの厄介な問題について話し合ったチームに特に感謝します。
* Benoit Claise
* ブノワ・クレーズ
* Watson Ladd
* ワトソン・ラッド
* Brad Peters
* ブラッド・ピーターズ
* Bo Wu
* ボー・ウー
* Georgios Karagiannis
* ゲオルギオス・カラギアンニス
* Olga Havel
* オルガ・ハベル
* Vincenzo Riccobene
* ヴィンチェンツォ・リッコベーネ
* Yi Lin
* イー・リン
* Jie Dong
* ジエ・ドン
* Aihua Guo
* 郭愛華
* Thomas Graf
* トーマス・グラフ
* Qin Wu
* 秦呉
* Chaode Yu
* チャオデ・ユ
* Adrian Farrel
* エイドリアン・ファレル
Nigel Davis (editor)
Ciena
United Kingdom
Email: ndavis@ciena.com
Adrian Farrel (editor)
Old Dog Consulting
United Kingdom
Email: adrian@olddog.co.uk
Thomas Graf
Swisscom
Binzring 17
CH-8045 Zurich
Switzerland
Email: thomas.graf@swisscom.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing
Jiangsu, 210012
China
Email: bill.wu@huawei.com
Chaode Yu
Huawei
Email: yuchaode@huawei.com