[要約] RFC 5706は、新しいプロトコルやプロトコル拡張の運用と管理を考慮するためのガイドラインです。その目的は、新しいプロトコルや拡張の導入における運用上の課題を識別し、効果的な管理手法を提供することです。
Network Working Group D. Harrington
Request for Comments: 5706 HuaweiSymantec USA
Category: Informational November 2009
Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions
新しいプロトコルとプロトコル拡張の運用と管理を検討するためのガイドライン
Abstract
概要
New protocols or protocol extensions are best designed with due consideration of the functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents that define new protocols or protocol extensions regarding aspects of operations and management that should be considered.
新しいプロトコルまたはプロトコル拡張は、プロトコルの操作と管理に必要な機能を十分に考慮して、最適に設計されています。改造運用と管理は最適です。このドキュメントの目的は、考慮すべき運用と管理の側面に関する新しいプロトコルまたはプロトコル拡張を定義するドキュメントの著者およびレビュー担当者にガイダンスを提供することです。
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Designing for Operations and Management ....................4
1.2. This Document ..............................................5
1.3. Motivation .................................................5
1.4. Background .................................................6
1.5. Available Management Technologies ..........................7
1.6. Terminology ................................................8
2. Operational Considerations - How Will the New Protocol
Fit into the Current Environment? ...............................8
2.1. Operations .................................................9
2.2. Installation and Initial Setup .............................9
2.3. Migration Path ............................................10
2.4. Requirements on Other Protocols and Functional
Components ................................................11
2.5. Impact on Network Operation ...............................11
2.6. Verifying Correct Operation ...............................12
3. Management Considerations - How Will the Protocol Be Managed? ..12
3.1. Interoperability ..........................................14
3.2. Management Information ....................................17
3.2.1. Information Model Design ...........................18
3.3. Fault Management ..........................................18
3.3.1. Liveness Detection and Monitoring ..................19
3.3.2. Fault Determination ................................19
3.3.3. Root Cause Analysis ................................20
3.3.4. Fault Isolation ....................................20
3.4. Configuration Management ..................................20
3.4.1. Verifying Correct Operation ........................22
3.5. Accounting Management .....................................22
3.6. Performance Management ....................................22
3.6.1. Monitoring the Protocol ............................23
3.6.2. Monitoring the Device ..............................24
3.6.3. Monitoring the Network .............................24
3.6.4. Monitoring the Service .............................25
3.7. Security Management .......................................25
4. Documentation Guidelines .......................................26
4.1. Recommended Discussions ...................................27
4.2. Null Manageability Considerations Sections ................27
4.3. Placement of Operations and Manageability
Considerations Sections ...................................28
5. Security Considerations ........................................28
6. Acknowledgements ...............................................28
7. Informative References .........................................29
Appendix A. Operations and Management Review Checklist ..........32
A.1. Operational Considerations ................................32
A.2. Management Considerations ................................34
A.3. Documentation .............................................35
Often when new protocols or protocol extensions are developed, not enough consideration is given to how the protocol will be deployed, operated, and managed. Retrofitting operations and management mechanisms is often hard and architecturally unpleasant, and certain protocol design choices may make deployment, operations, and management particularly hard. This document provides guidelines to help protocol designers and working groups consider the operations and management functionality for their new IETF protocol or protocol extension at an earlier phase.
多くの場合、新しいプロトコルまたはプロトコル拡張が開発された場合、プロトコルの展開、操作、および管理方法について十分な考慮が与えられません。操作と管理のメカニズムを改造することは困難であり、建築的に不快であり、特定のプロトコル設計の選択により、展開、運用、および管理が特に困難になる可能性があります。このドキュメントは、プロトコル設計者とワーキンググループが、以前のフェーズでの新しいIETFプロトコルまたはプロトコル拡張の運用と管理機能を検討するのを支援するガイドラインを提供します。
The operational environment and manageability of the protocol should be considered from the start when new protocols are designed.
プロトコルの運用環境と管理性は、新しいプロトコルが設計された最初から考慮する必要があります。
Most of the existing IETF management standards are focused on using Structure of Management Information (SMI)-based data models (MIB modules) to monitor and manage networking devices. As the Internet has grown, IETF protocols have addressed a constantly growing set of needs, such as web servers, collaboration services, and applications. The number of IETF management technologies has been expanding and the IETF management strategy has been changing to address the emerging management requirements. The discussion of emerging sets of management requirements has a long history in the IETF. The set of management protocols you should use depends on what you are managing.
既存のIETF管理標準のほとんどは、管理情報（SMI）ベースのデータモデル（MIBモジュール）の構造を使用して、ネットワーキングデバイスを監視および管理することに焦点を当てています。インターネットが成長するにつれて、IETFプロトコルは、Webサーバー、コラボレーションサービス、アプリケーションなど、常に増え続ける一連のニーズに対処しています。IETF管理技術の数が拡大しており、IETF管理戦略は、新たな管理要件に対処するために変化しています。新たな管理要件の議論には、IETFで長い歴史があります。使用する必要がある管理プロトコルのセットは、管理しているものによって異なります。
Protocol designers should consider which operations and management needs are relevant to their protocol, document how those needs could be addressed, and suggest (preferably standard) management protocols and data models that could be used to address those needs. This is similar to a working group (WG) that considers which security threats are relevant to their protocol, documents how threats should be mitigated, and then suggests appropriate standard protocols that could mitigate the threats.
プロトコル設計者は、どのオペレーションと管理ニーズがプロトコルに関連しているかを検討し、それらのニーズにどのように対処できるかを文書化し、それらのニーズに対処するために使用できる（できれば標準的な）管理プロトコルとデータモデルを提案する必要があります。これは、どのセキュリティの脅威がプロトコルに関連しているかを考慮し、脅威の緩和方法を文書化し、脅威を軽減できる適切な標準プロトコルを提案するワーキンググループ（WG）に似ています。
When a WG considers operation and management functionality for a protocol, the document should contain enough information for readers to understand how the protocol will be deployed and managed. The WG should expect that considerations for operations and management may need to be updated in the future, after further operational experience has been gained.
WGがプロトコルの運用と管理機能を考慮する場合、ドキュメントには、読者がプロトコルの展開と管理方法を理解するのに十分な情報を含める必要があります。WGは、運用の経験がさらに得られた後、運用と管理に関する考慮事項を将来更新する必要があると予想する必要があります。
This document makes a distinction between "Operational Considerations" and "Management Considerations", although the two are closely related. The section on manageability is focused on management technology, such as how to utilize management protocols and how to design management data models. The operational considerations apply to operating the protocol within a network, even if there were no management protocol actively being used.
このドキュメントは、「運用上の考慮事項」と「管理上の考慮事項」を区別しますが、2つは密接に関連しています。管理可能性に関するセクションは、管理プロトコルの利用方法や管理データモデルの設計方法など、管理技術に焦点を当てています。運用上の考慮事項は、積極的に使用されている管理プロトコルがなかったとしても、ネットワーク内のプロトコルの操作に適用されます。
The purpose of this document is to provide guidance about what to consider when thinking about the management and deployment of a new protocol, and to provide guidance about documenting the considerations. The following guidelines are designed to help writers provide a reasonably consistent format for such documentation. Separate manageability and operational considerations sections are desirable in many cases, but their structure and location is a decision that can be made from case to case.
このドキュメントの目的は、新しいプロトコルの管理と展開について考える際に考慮すべきことについてのガイダンスを提供し、考慮事項の文書化に関するガイダンスを提供することです。次のガイドラインは、作家がそのようなドキュメントに合理的に一貫した形式を提供するのを支援するように設計されています。多くの場合、個別の管理可能性と運用上の考慮事項セクションが望ましいものですが、その構造と場所はケースからケースまで行うことができる決定です。
This document does not impose a solution, imply that a formal data model is needed, or imply that using a specific management protocol is mandatory. If protocol designers conclude that the technology can be managed solely by using proprietary command line interfaces (CLIs) and that no structured or standardized data model needs to be in place, this might be fine, but it is a decision that should be explicit in a manageability discussion -- that this is how the protocol will need to be operated and managed. Protocol designers should avoid having manageability pushed for a later phase of the development of the standard.
このドキュメントは解決策を課すものではなく、正式なデータモデルが必要であることを暗示していること、または特定の管理プロトコルの使用が必須であることを意味します。プロトコル設計者が、独自のコマンドラインインターフェイス（CLI）を使用してテクノロジーを管理できると結論付けている場合、構造化されたデータモデルまたは標準化されたデータモデルを配置する必要はないが、これは問題ないかもしれませんが、それは明示的な決定です。管理可能性の議論 - これがプロトコルを操作および管理する必要がある方法です。プロトコル設計者は、標準の開発の後期段階に向けて管理性をプッシュすることを避ける必要があります。
In discussing the importance of considering operations and management, this document sets forth a list of guidelines and a checklist of questions to consider (see Appendix A), which a protocol designer or reviewer can use to evaluate whether the protocol and documentation address common operations and management needs. Operations and management are highly dependent on their environment, so most guidelines are subjective rather than objective.
運用と管理を検討することの重要性を議論する際に、このドキュメントでは、プロトコルデザイナーまたはレビュアーがプロトコルとドキュメンテーションが共通操作に対処するかどうかを評価するために使用できるガイドラインのリストと考慮すべき質問のチェックリスト（付録Aを参照）を示します。管理のニーズ。運用と管理は環境に大きく依存しているため、ほとんどのガイドラインは客観的ではなく主観的です。
For years the IETF community has used the IETF Standard Management Framework, including the Simple Network Management Protocol [RFC3410], the Structure of Management Information [RFC2578], and MIB data models for managing new protocols. As the Internet has evolved, operators have found the reliance on one protocol and one schema language for managing all aspects of the Internet inadequate. The IESG policy to require working groups to write a MIB module to provide manageability for new protocols is being replaced by a policy that is more open to using a variety of management protocols and data models designed to achieve different goals.
IETFコミュニティは、シンプルなネットワーク管理プロトコル[RFC3410]、管理情報の構造[RFC2578]、および新しいプロトコルを管理するためのMIBデータモデルなど、IETF標準管理フレームワークを使用してきました。インターネットが進化するにつれて、オペレーターは、インターネットのあらゆる側面を不十分に管理するための1つのプロトコルと1つのスキーマ言語への依存を発見しました。ワーキンググループに、新しいプロトコルの管理可能性を提供するためにMIBモジュールを作成するようにワーキンググループを要求するIESGポリシーは、さまざまな目標を達成するために設計されたさまざまな管理プロトコルとデータモデルを使用する方がオープンなポリシーに置き換えられています。
This document provides some initial guidelines for considering operations and management in an IETF Management Framework that consists of multiple protocols and multiple data-modeling languages, with an eye toward being flexible while also striving for interoperability.
このドキュメントは、複数のプロトコルと複数のデータモデリング言語で構成されるIETF管理フレームワークで、運用と管理を検討するためのいくつかの初期ガイドラインを提供し、相互運用性を目指して柔軟に努力しています。
Fully new protocols may require significant consideration of expected operations and management, while extensions to existing, widely deployed protocols may have established de facto operations and management practices that are already well understood.
完全に新しいプロトコルには、予想される運用と管理を大幅に考慮する必要がある場合がありますが、既存の広く展開されたプロトコルへの拡張により、すでに十分に理解されている事実上の運用と管理慣行が確立されている可能性があります。
Suitable management approaches may vary for different areas, working groups, and protocols in the IETF. This document does not prescribe a fixed solution or format in dealing with operational and management aspects of IETF protocols. However, these aspects should be considered for any IETF protocol because we develop technologies and protocols to be deployed and operated in the real-world Internet. It is fine if a WG decides that its protocol does not need interoperable management or no standardized data model, but this should be a deliberate decision, not the result of omission. This document provides some guidelines for those considerations.
適切な管理アプローチは、IETFのさまざまな分野、ワーキンググループ、およびプロトコルで異なる場合があります。このドキュメントは、IETFプロトコルの運用および管理の側面を扱う際の固定ソリューションまたは形式を規定していません。ただし、実際のインターネットで展開および操作するテクノロジーとプロトコルを開発するため、これらの側面は任意のIETFプロトコルで考慮する必要があります。WGがそのプロトコルが相互運用可能な管理または標準化されたデータモデルを必要としないことを決定した場合は問題ありませんが、これは省略の結果ではなく、意図的な決定でなければなりません。このドキュメントは、これらの考慮事項に関するいくつかのガイドラインを提供します。
There have been a significant number of efforts, meetings, and documents that are related to Internet operations and management. Some of them are mentioned here to help protocol designers find documentation of previous efforts. Hopefully, providing these references will help the IETF avoid rehashing old discussions and reinventing old solutions.
インターネットの運用と管理に関連するかなりの数の努力、会議、および文書がありました。それらのいくつかは、プロトコル設計者が以前の取り組みの文書を見つけるのを助けるためにここで言及されています。うまくいけば、これらの参照を提供することで、IETFが古い議論の再ハッシュや古いソリューションの再発明を避けるのに役立つことを願っています。
In 1988, the IAB published "IAB Recommendations for the Development of Internet Network Management Standards" [RFC1052], which recommended a solution that, where possible, deliberately separates modeling languages, data models, and the protocols that carry data. The goal is to allow standardized information and data models to be used by different protocols.
1988年、IABは「インターネットネットワーク管理標準の開発に関するIABの推奨事項」[RFC1052]を公開しました。これは、可能な限り、モデリング言語、データモデル、およびデータを運ぶプロトコルを意図的に分離するソリューションを推奨しました。目標は、標準化された情報とデータモデルを異なるプロトコルで使用できるようにすることです。
In 2001, Operations and Management Area design teams were created to document requirements related to the configuration of IP-based networks. One output was "Requirements for Configuration Management of IP-based Networks" [RFC3139].
2001年には、IPベースのネットワークの構成に関連する要件を文書化するために、運用および管理エリアの設計チームが作成されました。1つの出力は、「IPベースのネットワークの構成管理の要件」[RFC3139]でした。
In 2003, the Internet Architecture Board (IAB) held a workshop on Network Management [RFC3535] that discussed the strengths and weaknesses of some IETF network management protocols and compared them to operational needs, especially configuration.
2003年、インターネットアーキテクチャ委員会（IAB）は、IETFネットワーク管理プロトコルの長所と短所について議論し、運用上のニーズ、特に構成と比較するネットワーク管理に関するワークショップ[RFC3535]を開催しました。
One issue discussed was the user-unfriendliness of the binary format of SNMP [RFC3410] and Common Open Policy Service (COPS) Usage for Policy Provisioning (COPS-PR) [RFC3084], and it was recommended that the IETF explore an XML-based Structure of Management Information and an XML-based protocol for configuration.
議論された問題の1つは、SNMP [RFC3410]のバイナリ形式のユーザー非友好性と、ポリシープロビジョニング（COPS-PR）[RFC3084]のための一般的なオープンポリシーサービス（COPS）使用法であり、IETFがXMLベースのものを探索することをお勧めします。管理情報の構造と構成用のXMLベースのプロトコル。
Another conclusion was that the tools for event/alarm correlation and for root cause analysis and logging are not sufficient and that there is a need to support a human interface and a programmatic interface. The IETF decided to standardize aspects of the de facto standard for system-logging security and programmatic support.
別の結論は、イベント/アラーム相関と根本原因の分析とロギングのためのツールは十分ではなく、人間のインターフェイスとプログラムインターフェイスをサポートする必要があるということでした。IETFは、システムを解決するための事実上の標準の側面を標準化することを決定しました。
In 2006, the IETF discussed whether the Management Framework should be updated to accommodate multiple IETF schema languages for describing the structure of management information and multiple IETF standard protocols for performing management tasks. The IESG asked that a document be written to discuss how protocol designers and working groups should address management in this emerging multi-protocol environment. This document and some planned companion documents attempt to provide some guidelines for navigating the rapidly shifting operating and management environments.
2006年、IETFは、管理情報の構造と管理タスクを実行するための複数のIETF標準プロトコルを説明するための複数のIETFスキーマ言語に対応するために、管理フレームワークを更新すべきかどうかを議論しました。IESGは、プロトコル設計者とワーキンググループがこの新たなマルチプロトコル環境で管理にどのように対処するかを議論するために文書を書くように依頼しました。このドキュメントといくつかの計画されたコンパニオンドキュメントは、急速に変化する運用および管理環境をナビゲートするためのいくつかのガイドラインを提供しようとします。
The IETF has a number of standard management protocols available that are suitable for different purposes. These include:
IETFには、さまざまな目的に適した多くの標準管理プロトコルがあります。これらには以下が含まれます：
Simple Network Management Protocol - SNMP [RFC3410]
シンプルなネットワーク管理プロトコル-SNMP [RFC3410]
Syslog [RFC5424]
syslog [rfc5424]
Remote Authentication Dial-In User Service - RADIUS [RFC2865]
リモート認証ダイヤルユーザーサービス-RADIUS [RFC2865]
DIAMETER [RFC3588]
直径[RFC3588]
Network Configuration Protocol - NETCONF [RFC4741]
ネットワーク構成プロトコル-NetConf [RFC4741]
IP Flow Information Export - IPFIX [RFC5101]
IPフロー情報エクスポート-IPFIX [RFC5101]
A planned supplement to this document will discuss these protocol standards, discuss some standard information and data models for specific functionality, and provide pointers to the documents that define them.
このドキュメントの計画されたサプリメントでは、これらのプロトコル標準について説明し、特定の機能に関するいくつかの標準情報とデータモデルについて説明し、それらを定義するドキュメントへのポインターを提供します。
This document deliberately does not use the (capitalized) keywords described in RFC 2119 [RFC2119]. RFC 2119 states the keywords must only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions). For example, they must not be used to try to impose a particular method on implementers where the method is not required for interoperability. This informational document is a set of guidelines based on current practices of **some** protocol designers and operators. This document is biased toward router operations and management and some advice may not be directly applicable to protocols with a different purpose, such as application server protocols. This document **does not** describe interoperability requirements, so the capitalized keywords from RFC 2119 do not apply here.
このドキュメントは、RFC 2119 [RFC2119]に記載されている（大文字の）キーワードを意図的に使用していません。RFC 2119によると、キーワードは、相互操作に実際に必要な場合にのみ使用する必要がある場合、または害を引き起こす可能性のある行動を制限する必要がある場合にのみ使用する必要があります（たとえば、再送信の制限）。たとえば、相互運用性にメソッドが必要ない場合に、実装者に特定の方法を課そうとするために使用してはなりません。この情報文書は、**一部の**プロトコル設計者とオペレーターの現在のプラクティスに基づく一連のガイドラインです。このドキュメントはルーターの操作と管理に偏っており、いくつかのアドバイスは、アプリケーションサーバープロトコルなどの異なる目的を持つプロトコルに直接適用できない場合があります。このドキュメント**は、相互運用性の要件を説明していないため、RFC 2119の大文字のキーワードはここでは適用されません。
o CLI: Command Line Interface
o CLI：コマンドラインインターフェイス
o Data model: a mapping of the contents of an information model into a form that is specific to a particular type of data store or repository [RFC3444].
o データモデル：情報モデルの内容を、特定のタイプのデータストアまたはリポジトリ[RFC3444]に固有のフォームにマッピングします。
o Information model: an abstraction and representation of the entities in a managed environment, their properties, attributes and operations, and the way that they relate to each other. It is independent of any specific repository, software usage, protocol, or platform [RFC3444].
o 情報モデル：管理された環境でのエンティティの抽象化と表現、そのプロパティ、属性、運用、およびそれらが互いに関連する方法。特定のリポジトリ、ソフトウェアの使用、プロトコル、またはプラットフォーム[RFC3444]に依存しません。
o New protocol: includes new protocols, protocol extensions, data models, or other functionality being designed.
o 新しいプロトコル：新しいプロトコル、プロトコル拡張、データモデル、または設計されているその他の機能が含まれます。
o Protocol designer: represents individuals and working groups involved in the development of new protocols or extensions.
o プロトコルデザイナー：新しいプロトコルまたは拡張機能の開発に関与する個人およびワーキンググループを表します。
Designers of a new protocol should carefully consider the operational aspects. To ensure that a protocol will be practical to deploy in the real world, it is not enough to merely define it very precisely in a well-written document. Operational aspects will have a serious impact on the actual success of a protocol. Such aspects include bad interactions with existing solutions, a difficult upgrade path, difficulty of debugging problems, difficulty configuring from a central database, or a complicated state diagram that operations staff will find difficult to understand.
新しいプロトコルの設計者は、運用上の側面を慎重に検討する必要があります。プロトコルが現実の世界で展開するのが実用的であることを確認するには、よく書かれたドキュメントで非常に正確に定義するだけでは不十分です。運用上の側面は、プロトコルの実際の成功に深刻な影響を与えます。このような側面には、既存のソリューションとの悪い相互作用、困難なアップグレードパス、問題のデバッグの難しさ、中央データベースからの構成の難しさ、または運用スタッフが理解するのが難しいと感じる複雑な状態図が含まれます。
BGP flap damping [RFC2439] is an example. It was designed to block high-frequency route flaps; however, the design did not consider the existence of BGP path exploration / slow convergence. In real operations, path exploration caused false flap damping, resulting in loss of reachability. As a result, many networks turned flap damping off.
BGPフラップ減衰[RFC2439]は例です。高周波ルートフラップをブロックするように設計されています。ただし、設計では、BGPパス探索 /遅い収束の存在を考慮していませんでした。実際の操作では、経路探査により誤ったフラップ減衰が発生し、到達可能性が失われました。その結果、多くのネットワークがフラップの減衰をオフにしました。
Protocol designers can analyze the operational environment and mode of work in which the new protocol or extension will work. Such an exercise need not be reflected directly by text in their document, but could help in visualizing how to apply the protocol in the Internet environments where it will be deployed.
プロトコル設計者は、新しいプロトコルまたは拡張機能が機能する運用環境と作業モードを分析できます。このような演習は、ドキュメントのテキストによって直接反映される必要はありませんが、展開されるインターネット環境でプロトコルを適用する方法を視覚化するのに役立ちます。
A key question is how the protocol can operate "out of the box". If implementers are free to select their own defaults, the protocol needs to operate well with any choice of values. If there are sensible defaults, these need to be stated.
重要な質問は、プロトコルが「箱から出して」動作する方法です。実装者が独自のデフォルトを自由に選択できる場合、プロトコルはどんな選択でもうまく動作する必要があります。賢明なデフォルトがある場合、これらを記載する必要があります。
There may be a need to support a human interface, e.g., for troubleshooting, and a programmatic interface, e.g., for automated monitoring and root cause analysis. The application programming interfaces and the human interfaces might benefit from being similar to ensure that the information exposed by these two interfaces is consistent when presented to an operator. Identifying consistent methods of determining information, such as what gets counted in a specific counter, is relevant.
たとえば、トラブルシューティングやプログラマティックインターフェイスなど、自動監視および根本原因分析のために、人間のインターフェイスをサポートする必要があるかもしれません。アプリケーションプログラミングインターフェイスと人間のインターフェイスは、これらの2つのインターフェイスによって公開される情報がオペレーターに提示されたときに一貫していることを確認するために似ていることから利益を得ることができます。特定のカウンターでカウントされるものなど、情報を決定する一貫した方法を特定することは関連性があります。
Protocol designers should consider what management operations are expected to be performed as a result of the deployment of the protocol -- such as whether write operations will be allowed on routers and on hosts, or whether notifications for alarms or other events will be expected.
プロトコル設計者は、プロトコルの展開の結果として管理操作が実行されると予想されるものを検討する必要があります。これは、ルーターやホストでの書き込み操作が許可されるか、アラームまたはその他のイベントの通知が予想されるかなどです。
Anything that can be configured can be misconfigured. "Architectural Principles of the Internet" [RFC1958], Section 3.8, states: "Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually."
構成できるものはすべて、誤って構成できます。「インターネットの建築原則」[RFC1958]、セクション3.8は次のように述べています。「可能な限りオプションとパラメーターを避けてください。オプションとパラメーターは、手動ではなく動的に構成または交渉する必要があります。」
To simplify configuration, protocol designers should consider specifying reasonable defaults, including default modes and parameters. For example, it could be helpful or necessary to specify default values for modes, timers, default state of logical control variables, default transports, and so on. Even if default values are used, it must be possible to retrieve all the actual values or at least an indication that known default values are being used.
構成を簡素化するには、プロトコル設計者は、デフォルトのモードやパラメーターを含む合理的なデフォルトを指定することを検討する必要があります。たとえば、モード、タイマー、論理制御変数のデフォルトの状態、デフォルトのトランスポートなどのデフォルト値を指定することが役立つか、必要になる可能性があります。デフォルト値が使用されていても、すべての実際の値を取得すること、または少なくとも既知のデフォルト値が使用されていることを示すことができる必要があります。
Protocol designers should consider how to enable operators to concentrate on the configuration of the network as a whole rather than on individual devices. Of course, how one accomplishes this is the hard part.
プロトコル設計者は、オペレーターが個々のデバイスではなく、ネットワーク全体の構成に集中できるようにする方法を検討する必要があります。もちろん、これを達成する方法は難しい部分です。
It is desirable to discuss the background of chosen default values, or perhaps why a range of values makes sense. In many cases, as technology changes, the values in an RFC might make less and less sense. It is very useful to understand whether defaults are based on best current practice and are expected to change as technologies advance or whether they have a more universal value that should not be changed lightly. For example, the default interface speed might be expected to change over time due to increased speeds in the network, and cryptographical algorithms might be expected to change over time as older algorithms are "broken".
選択したデフォルト値の背景、またはおそらくさまざまな値が理にかなっている理由について議論することが望ましいです。多くの場合、テクノロジーが変化するにつれて、RFCの値はますます少なくなる可能性があります。デフォルトが最良の現在のプラクティスに基づいており、テクノロジーが前進するにつれて変更されると予想されるかどうか、または軽く変更すべきではないより普遍的な価値があるかどうかを理解することは非常に便利です。たとえば、ネットワークの速度が上昇するため、デフォルトのインターフェイス速度は時間とともに変化すると予想される場合があり、古いアルゴリズムが「壊れている」ため、暗号化アルゴリズムが時間とともに変化すると予想される場合があります。
It is extremely important to set a sensible default value for all parameters.
すべてのパラメーターに賢明なデフォルト値を設定することが非常に重要です。
The default value should stay on the conservative side rather than on the "optimizing performance" side (example: the initial RTT and RTTvar values of a TCP connection).
デフォルト値は、「パフォーマンスの最適化」側ではなく、保守的な側面にとどまる必要があります（例：TCP接続の初期RTTおよびRTTVAR値）。
For those parameters that are speed-dependent, instead of using a constant, try to set the default value as a function of the link speed or some other relevant factors. This would help reduce the chance of problems caused by technology advancement.
速度依存のパラメーターについては、定数を使用する代わりに、デフォルト値をリンク速度またはその他の関連要因の関数として設定するようにしてください。これは、テクノロジーの進歩によって引き起こされる問題の可能性を減らすのに役立ちます。
If the new protocol is a new version of an existing one, or if it is replacing another technology, the protocol designer should consider how deployments should transition to the new protocol. This should include coexistence with previously deployed protocols and/or previous versions of the same protocol, incompatibilities between versions, translation between versions, and side effects that might occur. Are older protocols or versions disabled or do they coexist in the network with the new protocol?
新しいプロトコルが既存のプロトコルの新しいバージョンである場合、または別のテクノロジーを置き換えている場合、プロトコル設計者は展開が新しいプロトコルへの移行方法を検討する必要があります。これには、以前に展開されたプロトコルおよび/または同じプロトコルの以前のバージョンとの共存、バージョン間の非互換性、バージョン間の翻訳、および発生する可能性のある副作用が含まれる必要があります。古いプロトコルまたはバージョンは無効になっていますか、それとも新しいプロトコルとネットワークに共存していますか？
Many protocols benefit from being incrementally deployable -- operators may deploy aspects of a protocol before deploying the protocol fully.
多くのプロトコルは、段階的に展開可能であることから恩恵を受けます。オペレーターは、プロトコルを完全に展開する前に、プロトコルの側面を展開することができます。
Protocol designers should consider the requirements that the new protocol might put on other protocols and functional components and should also document the requirements from other protocols and functional elements that have been considered in designing the new protocol.
プロトコル設計者は、新しいプロトコルが他のプロトコルや機能コンポーネントに掲載する可能性のある要件を考慮し、新しいプロトコルの設計で考慮された他のプロトコルおよび機能要素からの要件も文書化する必要があります。
These considerations should generally remain illustrative to avoid creating restrictions or dependencies, or potentially impacting the behavior of existing protocols, or restricting the extensibility of other protocols, or assuming other protocols will not be extended in certain ways. If restrictions or dependencies exist, they should be stated.
これらの考慮事項は、通常、制限や依存関係の作成を避けたり、既存のプロトコルの動作に影響を与えたり、他のプロトコルの拡張性を制限したり、他のプロトコルが特定の方法で拡張されないと仮定することを避けるために、例示的なままでなければなりません。制限または依存関係が存在する場合、それらを記載する必要があります。
For example, the design of the Resource ReSerVation Protocol (RSVP) [RFC2205] required each router to look at the RSVP PATH message and, if the router understood RSVP, add its own address to the message to enable automatic tunneling through non-RSVP routers. But in reality, routers cannot look at an otherwise normal IP packet and potentially take it off the fast path! The initial designers overlooked that a new "deep packet inspection" requirement was being put on the functional components of a router. The "router alert" option ([RFC2113], [RFC2711]) was finally developed to solve this problem for RSVP and other protocols that require the router to take some packets off the fast-forwarding path. Yet, router alert has its own problems in impacting router performance.
たとえば、リソース予約プロトコル（RSVP）[RFC2205]の設計では、各ルーターがRSVPパスメッセージを調べる必要があり、ルーターがRSVPを理解した場合、メッセージに独自のアドレスを追加して、非RSVPルーターを介して自動トンネリングを可能にするために独自のアドレスを追加します。。しかし、実際には、ルーターはそれ以外の場合は通常のIPパケットを見ることができず、潜在的に高速パスからそれを取り除くことができません！最初の設計者は、ルーターの機能的なコンポーネントに新しい「深いパケット検査」要件が置かれていることを見落としていました。「ルーターアラート」オプション（[RFC2113]、[RFC2711]）が最終的に開発され、RSVPや、ルーターがいくつかのパケットを高速パスから取り除く必要がある他のプロトコルのこの問題を解決しました。しかし、ルーターアラートには、ルーターのパフォーマンスに影響を与える際に独自の問題があります。
The introduction of a new protocol or extensions to an existing protocol may have an impact on the operation of existing networks. Protocol designers should outline such impacts (which may be positive), including scaling concerns and interactions with other protocols. For example, a new protocol that doubles the number of active, reachable addresses in use within a network might need to be considered in the light of the impact on the scalability of the interior gateway protocols operating within the network.
既存のプロトコルへの新しいプロトコルまたは拡張機能の導入は、既存のネットワークの動作に影響を与える可能性があります。プロトコル設計者は、スケーリングの懸念や他のプロトコルとの相互作用など、そのような影響（プラスの可能性がある）の概要を説明する必要があります。たとえば、ネットワーク内で動作するインテリアゲートウェイプロトコルのスケーラビリティへの影響に照らして、ネットワーク内で使用されているアクティブでリーチ可能なアドレスの数を2倍にする新しいプロトコルを考慮する必要がある場合があります。
A protocol could send active monitoring packets on the wire. If we don't pay attention, we might get very good accuracy, but could send too many active monitoring packets.
プロトコルは、ワイヤーにアクティブな監視パケットを送信できます。注意を払わなければ、非常に精度が得られるかもしれませんが、アクティブな監視パケットが多すぎる可能性があります。
The protocol designer should consider the potential impact on the behavior of other protocols in the network and on the traffic levels and traffic patterns that might change, including specific types of traffic, such as multicast. Also, consider the need to install new components that are added to the network as a result of changes in the configuration, such as servers performing auto-configuration operations.
The protocol designer should consider also the impact on infrastructure applications like DNS [RFC1034], the registries, or the size of routing tables. For example, Simple Mail Transfer Protocol (SMTP) [RFC5321] servers use a reverse DNS lookup to filter out incoming connection requests. When Berkeley installed a new spam filter, their mail server stopped functioning because of overload of the DNS cache resolver.
プロトコル設計者は、DNS [RFC1034]、レジストリ、またはルーティングテーブルのサイズなどのインフラストラクチャアプリケーションへの影響も考慮する必要があります。たとえば、Simple Mail転送プロトコル（SMTP）[RFC5321]サーバーは、逆DNSルックアップを使用して、着信接続要求をフィルタリングします。Berkeleyが新しいスパムフィルターをインストールしたとき、DNSキャッシュリゾルバーの過負荷のため、メールサーバーは機能を停止しました。
The impact on performance may also be noted -- increased delay or jitter in real-time traffic applications, or increased response time in client-server applications when encryption or filtering are applied.
パフォーマンスへの影響は、リアルタイムトラフィックアプリケーションの遅延またはジッターの増加、または暗号化またはフィルタリングが適用されたときのクライアントサーバーアプリケーションでの応答時間の増加にも注意することができます。
It is important to minimize the impact caused by configuration changes. Given configuration A and configuration B, it should be possible to generate the operations necessary to get from A to B with minimal state changes and effects on network and systems.
構成の変更によって引き起こされる影響を最小限に抑えることが重要です。構成Aと構成Bを与えられている場合、ネットワークとシステムの状態の変更と影響を最小限に抑えて、AからBからBを取得するために必要な操作を生成することが可能である必要があります。
The protocol designer should consider techniques for testing the effect that the protocol has had on the network by sending data through the network and observing its behavior (aka active monitoring). Protocol designers should consider how the correct end-to-end operation of the new protocol in the network can be tested actively and passively, and how the correct data or forwarding plane function of each network element can be verified to be working properly with the new protocol. Which metrics are of interest?
プロトコル設計者は、ネットワークを介してデータを送信し、その動作を観察することにより、プロトコルがネットワークに与えた効果をテストするための手法を検討する必要があります（別名アクティブモニタリング）。プロトコル設計者は、ネットワーク内の新しいプロトコルの正しいエンドツーエンド操作を積極的かつ受動的にテストする方法、および各ネットワーク要素の正しいデータまたは転送面機能を新しいものと正しく連携することを検証する方法を考慮する必要がありますプロトコル。どのメトリックが興味深いですか？
Having simple protocol status and health indicators on network devices is a recommended means to check correct operation.
ネットワークデバイスに単純なプロトコルステータスと健康指標を持つことは、正しい操作を確認するための推奨手段です。
The considerations of manageability should start from identifying the entities to be managed, as well as how the managed protocol is supposed to be installed, configured, and monitored.
管理可能性の考慮事項は、管理されるエンティティの識別から始まり、マネージドプロトコルのインストール、構成、監視方法を想定する方法から開始する必要があります。
Considerations for management should include a discussion of what needs to be managed, and how to achieve various management tasks. Where are the managers and what type of management interfaces and protocols will they need? The "write a MIB module" approach to considering management often focuses on monitoring a protocol endpoint on a single device. A MIB module document typically only considers monitoring properties observable at one end, while the document does not really cover managing the *protocol* (the coordination of multiple ends), and does not even come near managing the *service* (which includes a lot of stuff that is very far away from the box). This is exactly what operators hate -- you need to be able to manage both ends. As [RFC3535] says, "MIB modules can often be characterized as a list of ingredients without a recipe".
経営陣の考慮事項には、管理する必要があるものと、さまざまな管理タスクを達成する方法の議論が含まれる必要があります。マネージャーはどこにあり、どのような種類の管理インターフェイスとプロトコルが必要ですか？管理を検討するための「MIBモジュールの書き込み」アプローチは、多くの場合、単一のデバイスのプロトコルエンドポイントの監視に焦点を当てています。MIBモジュールドキュメントは通常、一端で観測可能な監視プロパティのみを考慮しますが、ドキュメントは *プロトコル *（複数の端の調整）の管理を実際にカバーせず、 *サービス *の管理に近づくことさえありません（箱から非常に遠くにあるものの）。これはまさにオペレーターが嫌いなものです。両端を管理できる必要があります。[RFC3535]が言うように、「MIBモジュールは、レシピのない成分のリストとして特徴付けられることがよくあります」。
The management model should take into account factors such as:
管理モデルは、次のような要因を考慮する必要があります。
o What type of management entities will be involved (agents, network management systems)?
o どのような種類の管理エンティティが関与しますか（エージェント、ネットワーク管理システム）？
o What is the possible architecture (client-server, manager-agent, poll-driven or event-driven, auto-configuration, two levels or hierarchical)?
o 可能なアーキテクチャ（クライアントサーバー、マネージャーエージェント、投票主導またはイベント駆動型、自動構成、2つのレベルまたは階層）は何ですか？
o What are the management operations (initial configuration, dynamic configuration, alarm and exception reporting, logging, performance monitoring, performance reporting, debugging)?
o 管理操作（初期構成、動的構成、アラーム、例外報告、ロギング、パフォーマンス監視、パフォーマンスレポート、デバッグ）とは何ですか？
o How are these operations performed (locally, remotely, atomic operation, scripts)? Are they performed immediately or are they time scheduled or event triggered?
o これらの操作はどのように実行されますか（ローカル、リモート、原子操作、スクリプト）？それらはすぐに実行されますか、それとも時間が予定されていますか、それともイベントがトリガーされていますか？
Protocol designers should consider how the new protocol will be managed in different deployment scales. It might be sensible to use a local management interface to manage the new protocol on a single device, but in a large network, remote management using a centralized server and/or using distributed management functionality might make more sense. Auto-configuration and default parameters might be possible for some new protocols.
プロトコル設計者は、新しいプロトコルがさまざまな展開スケールでどのように管理されるかを検討する必要があります。ローカルマネジメントインターフェイスを使用して単一のデバイスで新しいプロトコルを管理することは賢明かもしれませんが、大規模なネットワークでは、集中サーバーを使用したり、分散管理機能を使用したりするリモート管理がより理にかなっている場合があります。一部の新しいプロトコルでは、自動構成とデフォルトのパラメーターが可能になる場合があります。
Management needs to be considered not only from the perspective of a device, but also from the perspective of network and service management. A service might be network and operational functionality derived from the implementation and deployment of a new protocol. Often an individual network element is not aware of the service being delivered.
管理は、デバイスの観点からだけでなく、ネットワークとサービス管理の観点からも考慮する必要があります。サービスは、新しいプロトコルの実装と展開から派生したネットワークおよび運用機能です。多くの場合、個々のネットワーク要素が配信されているサービスを認識していません。
WGs should consider how to configure multiple related/co-operating devices and how to back off if one of those configurations fails or causes trouble. NETCONF [RFC4741] addresses this in a generic manner by allowing an operator to lock the configuration on multiple devices, perform the configuration settings/changes, check that they are OK (undo if not), and then unlock the devices.
WGSは、複数の関連/採用デバイスを構成する方法と、それらの構成のいずれかが失敗または問題を引き起こす場合にバックオフする方法を検討する必要があります。NetConf [RFC4741]は、オペレーターが複数のデバイスで構成をロックし、構成設定/変更を実行し、OK（元に戻していない場合は元に戻す）を確認し、デバイスのロックを解除できるようにすることにより、一般的な方法でこれに対処します。
Techniques for debugging protocol interactions in a network must be part of the network-management discussion. Implementation source code should be debugged before ever being added to a network, so asserts and memory dumps do not normally belong in management data models. However, debugging on-the-wire interactions is a protocol issue: while the messages can be seen by sniffing, it is enormously helpful if a protocol specification supports features that make debugging of network interactions and behaviors easier. There could be alerts issued when messages are received or when there are state transitions in the protocol state machine. However, the state machine is often not part of the on-the-wire protocol; the state machine explains how the protocol works so that an implementer can decide, in an implementation-specific manner, how to react to a received event.
ネットワークでのプロトコルインタラクションをデバッグするための手法は、ネットワーク管理の議論の一部でなければなりません。実装ソースコードは、ネットワークに追加される前にデバッグする必要があるため、通常は管理データモデルに属していないアサートとメモリダンプはありません。ただし、ワイヤーでのインタラクションのデバッグはプロトコルの問題です。メッセージはスニッフィングで確認できますが、プロトコル仕様がネットワークの相互作用と動作のデバッグを簡単にする機能をサポートする場合、非常に役立ちます。メッセージが受信されたとき、またはプロトコル状態マシンに状態遷移があるときにアラートが発行される可能性があります。ただし、状態マシンは、多くの場合、ワイヤー内のプロトコルの一部ではありません。State Machineは、プロトコルがどのように機能するかを説明し、実装者が実装固有の方法で受信したイベントにどのように対応するかを決定できるようにします。
In a client/server protocol, it may be more important to instrument the server end of a protocol than the client end, since the performance of the server might impact more nodes than the performance of a specific client.
クライアント/サーバーのプロトコルでは、サーバーのパフォーマンスは特定のクライアントのパフォーマンスよりも多くのノードに影響を与える可能性があるため、クライアントのエンドよりもプロトコルのサーバーの終了を計測することが重要かもしれません。
Just as when deploying protocols that will inter-connect devices, management interoperability should be considered -- whether across devices from different vendors, across models from the same vendor, or across different releases of the same product. Management interoperability refers to allowing information sharing and operations between multiple devices and multiple management applications, often from different vendors. Interoperability allows for the use of third-party applications and the outsourcing of management services.
デバイスを相互接続するプロトコルを展開するときと同じように、管理の相互運用性を考慮する必要があります - 異なるベンダーのデバイス全体、同じベンダーのモデル間、または同じ製品の異なるリリース間で。管理の相互運用性とは、多くの場合、さまざまなベンダーからの複数のデバイスと複数の管理アプリケーション間の情報共有と操作を許可することを指します。相互運用性により、サードパーティアプリケーションの使用と管理サービスのアウトソーシングが可能になります。
Some product designers and protocol designers assume that if a device can be managed individually using a command line interface or a web page interface, that such a solution is enough. But when equipment from multiple vendors is combined into a large network, scalability of management may become a problem. It may be important to have consistency in the management interfaces so network-wide operational processes can be automated. For example, a single switch might be easily managed using an interactive web interface when installed in a single-office small business, but when, say, a fast-food company installs similar switches from multiple vendors in hundreds or thousands of individual branches and wants to automate monitoring them from a central location, monitoring vendor- and model-specific web pages would be difficult to automate.
一部の製品設計者およびプロトコルデザイナーは、コマンドラインインターフェイスまたはWebページインターフェイスを使用してデバイスを個別に管理できる場合、そのようなソリューションで十分であると想定しています。しかし、複数のベンダーからの機器が大規模なネットワークに結合されると、管理のスケーラビリティが問題になる可能性があります。ネットワーク全体の運用プロセスを自動化できるため、管理インターフェイスに一貫性があることが重要かもしれません。たとえば、単一のスイッチは、単一オフィスの中小企業にインストールされたときにインタラクティブなWebインターフェイスを使用して簡単に管理できますが、たとえばファーストフード会社が数百または数千の個々の支店で複数のベンダーから同様のスイッチをインストールすると、中央の場所からそれらを監視することを自動化するには、ベンダーおよびモデル固有のWebページを監視するのは難しいでしょう。
The primary goal is the ability to roll out new useful functions and services in a way in which they can be managed in a scalable manner, where one understands the network impact (as part of the total cost of operations) of that service.
主な目標は、新しい有用な機能とサービスをスケーラブルな方法で管理できる方法で展開する能力であり、そのサービスのネットワークへの影響（総運用コストの一部として）を理解することです。
Getting everybody to agree on a single syntax and an associated protocol to do all management has proven to be difficult. So management systems tend to speak whatever the boxes support, whether or not the IETF likes this. The IETF is moving from support for one schema language for modeling the structure of management information (Structure of Management Information Version 2 (SMIv2) [RFC2578]) and one simple network management protocol (Simple Network Management Protocol (SNMP) [RFC3410]) towards support for additional schema languages and additional management protocols suited to different purposes. Other Standard Development Organizations (e.g., the Distributed Management Task Force - DMTF, the Tele-Management Forum - TMF) also define schemas and protocols for management and these may be more suitable than IETF schemas and protocols in some cases. Some of the alternatives being considered include:
すべての管理を行うための単一の構文と関連するプロトコルに全員に同意させることは、困難であることが証明されています。そのため、管理システムは、IETFがこれを好むかどうかにかかわらず、ボックスがサポートするものを何でも話す傾向があります。IETFは、管理情報の構造（管理情報の構造バージョン2（SMIV2）[RFC2578]）と1つの単純なネットワーク管理プロトコル（Simple Network Management Protocol（SNMP）[RFC3410]）の構造をモデル化するための1つのスキーマ言語のサポートから移行しています。さまざまな目的に適した追加のスキーマ言語と追加の管理プロトコルのサポート。その他の標準開発組織（例：分散管理タスクフォース-DMTF、Tele -Management Forum -TMF）も管理のためのスキーマとプロトコルを定義しており、これらは場合によってはIETFスキーマやプロトコルよりも適している可能性があります。考慮される代替案のいくつかは次のとおりです。
o XML Schema Definition [W3C.REC-xmlschema-0-20010502]
o XMLスキーマ定義[W3C.REC-XMLSCHEMA-0-20010502]
and
と
o NETCONF Configuration Protocol [RFC4741]
o NetConf構成プロトコル[RFC4741]
o the IP Flow Information Export (IPFIX) Protocol [RFC5101]) for usage accounting
o IP Flow Information Export（IPFIX）プロトコル[RFC5101]）使用会計用
o the syslog protocol [RFC5424] for logging
o ロギング用のSyslogプロトコル[RFC5424]
Interoperability needs to be considered on the syntactic level and the semantic level. While it can be irritating and time-consuming, application designers, including operators who write their own scripts, can make their processing conditional to accommodate syntactic differences across vendors, models, or releases of product.
相互運用性は、構文レベルとセマンティックレベルで考慮する必要があります。刺激的で時間がかかる可能性がありますが、独自のスクリプトを書くオペレーターを含むアプリケーションデザイナーは、ベンダー、モデル、または製品のリリース間の構文の違いに対応するために処理を条件とすることができます。
Semantic differences are much harder to deal with on the manager side -- once you have the data, its meaning is a function of the managed entity.
意味の違いは、マネージャー側で対処するのがはるかに困難です。データが得られたら、その意味はマネージドエンティティの関数です。
Information models are helpful to try to focus interoperability on the semantic level -- they establish standards for what information should be gathered and how gathered information might be used, regardless of which management interface carries the data or which vendor produces the product. The use of an information model might help improve the ability of operators to correlate messages in different protocols where the data overlaps, such as a syslog message and an SNMP notification about the same event. An information model might identify which error conditions should be counted separately and which error conditions can be counted together in a single counter. Then, whether the counter is gathered via SNMP, a CLI command, or a syslog message, the counter will have the same meaning.
情報モデルは、相互運用性をセマンティックレベルに集中しようとするのに役立ちます。どのような情報を収集すべきか、どの管理インターフェイスがデータを運ぶか、どのベンダーが製品を生成するかに関係なく、どのように収集された情報を使用するかについての標準を確立します。情報モデルを使用すると、Syslogメッセージや同じイベントに関するSNMP通知など、データが重複するさまざまなプロトコルのメッセージを相関させるオペレーターの能力を改善するのに役立つ可能性があります。情報モデルは、どのエラー条件を個別にカウントするか、単一のカウンターで一緒にカウントできるエラー条件を特定する場合があります。次に、カウンターがSNMP、CLIコマンド、またはsyslogメッセージを介して収集されるかどうかにかかわらず、カウンターは同じ意味を持ちます。
Protocol designers should consider which information might be useful for managing the new protocol or protocol extensions.
プロトコル設計者は、新しいプロトコルまたはプロトコル拡張の管理に役立つ情報を考慮する必要があります。
IM --> conceptual/abstract model
| for designers and operators
+----------+---------+
| | |
DM DM DM --> concrete/detailed model
for implementers
Information Models and Data Models
情報モデルとデータモデル
Figure 1
図1
Protocol designers may decide an information model or data model would be appropriate for managing the new protocol or protocol extensions.
プロトコル設計者は、情報モデルまたはデータモデルが新しいプロトコルまたはプロトコル拡張を管理するのに適していると判断する場合があります。
"On the Difference between Information Models and Data Models" [RFC3444] can be helpful in determining what information to consider regarding information models (IMs), as compared to data models (DMs).
「情報モデルとデータモデルの違いについて」[RFC3444]は、データモデル（DM）と比較して、情報モデル（IMS）に関する情報を考慮する情報を決定するのに役立ちます。
Information models should come from the protocol WGs and include lists of events, counters, and configuration parameters that are relevant. There are a number of information models contained in protocol WG RFCs. Some examples:
情報モデルは、プロトコルWGSから来て、関連するイベント、カウンター、構成パラメーターのリストを含める必要があります。プロトコルWG RFCに含まれる多くの情報モデルがあります。いくつかの例：
o [RFC3060] - Policy Core Information Model version 1
o [RFC3060] - ポリシーコア情報モデルバージョン1
o [RFC3290] - An Informal Management Model for Diffserv Routers
o [RFC3290] - Diffservルーターの非公式管理モデル
o [RFC3460] - Policy Core Information Model Extensions
o [RFC3460] - ポリシーコア情報モデルの拡張
o [RFC3585] - IPsec Configuration Policy Information Model
o [RFC3585] -IPSEC構成ポリシー情報モデル
o [RFC3644] - Policy Quality of Service Information Model
o [RFC3644] - サービス情報のポリシー品質モデル
o [RFC3670] - Information Model for Describing Network Device QoS Datapath Mechanisms
o [RFC3670] - ネットワークデバイスQoSデータパスメカニズムを説明するための情報モデル
o [RFC3805] - Printer MIB v2 (contains both an IM and a DM) Management protocol standards and management data model standards often contain compliance clauses to ensure interoperability. Manageability considerations should include discussion of which level of compliance is expected to be supported for interoperability.
o [RFC3805] - プリンターMIB V2（IMとA DMの両方が含まれています）管理プロトコル標準と管理データモデルの標準には、相互運用性を確保するためのコンプライアンス条項が含まれています。管理可能性の考慮事項には、相互運用性のためにどのレベルのコンプライアンスがサポートされるかについての議論を含める必要があります。
Languages used to describe an information model can influence the nature of the model. Using a particular data-modeling language, such as the SMIv2, influences the model to use certain types of structures, such as two-dimensional tables. This document recommends using English text (the official language for IETF specifications) to describe an information model. A sample data model could be developed to demonstrate the information model.
情報モデルを説明するために使用される言語は、モデルの性質に影響を与える可能性があります。SMIV2などの特定のデータモデリング言語を使用すると、2次元テーブルなどの特定のタイプの構造を使用するためにモデルに影響します。このドキュメントでは、情報モデルを説明するために英語のテキスト（IETF仕様の公式言語）を使用することをお勧めします。情報モデルを実証するために、サンプルデータモデルを開発できます。
A management information model should include a discussion of what is manageable, which aspects of the protocol need to be configured, what types of operations are allowed, what protocol-specific events might occur, which events can be counted, and for which events an operator should be notified.
管理情報モデルには、管理可能なもの、プロトコルのどの側面を構成する必要があるか、許可される操作の種類、プロトコル固有のイベントが発生する可能性のあるイベント、およびオペレーターのイベントについての議論を含める必要があります。通知する必要があります。
Operators find it important to be able to make a clear distinction between configuration data, operational state, and statistics. They need to determine which parameters were administratively configured and which parameters have changed since configuration as the result of mechanisms such as routing protocols or network management protocols. It is important to be able to separately fetch current configuration information, initial configuration information, operational state information, and statistics from devices; to be able to compare current state to initial state; and to compare information between devices. So when deciding what information should exist, do not conflate multiple information elements into a single element.
オペレーターは、構成データ、運用状態、統計を明確に区別できることが重要だと感じています。ルーティングプロトコルやネットワーク管理プロトコルなどのメカニズムの結果として、構成以来、どのパラメーターが管理上構成され、どのパラメーターが変更されているかを決定する必要があります。現在の構成情報、初期構成情報、運用状態情報、およびデバイスからの統計を個別に取得できることが重要です。現在の状態と初期状態を比較できるようにする。デバイス間の情報を比較します。したがって、どの情報が存在するかを決定するときは、複数の情報要素を単一の要素に合わせないでください。
What is typically difficult to work through are relationships between abstract objects. Ideally, an information model would describe the relationships between the objects and concepts in the information model.
通常作業するのが難しいのは、抽象的なオブジェクト間の関係です。理想的には、情報モデルは、情報モデルのオブジェクトと概念間の関係を説明します。
Is there always just one instance of this object or can there be multiple instances? Does this object relate to exactly one other object or may it relate to multiple? When is it possible to change a relationship? Do objects (such as rows in tables) share fate? For example, if a row in table A must exist before a related row in table B can be created, what happens to the row in table B if the related row in table A is deleted? Does the existence of relationships between objects have an impact on fate sharing?
このオブジェクトのインスタンスは常に1つだけありますか、それとも複数のインスタンスがありますか？このオブジェクトは、他の1つのオブジェクトに関連していますか、それとも複数に関連する可能性がありますか？関係を変えることはいつ可能ですか？オブジェクト（テーブルの行など）は運命を共有していますか？たとえば、テーブルAの行AがテーブルBの関連する行を作成する前に存在する必要がある場合、表Aの関連する行が削除された場合、表Bの行はどうなりますか？オブジェクト間の関係の存在は、運命共有に影響を与えますか？
This document recommends keeping the information model as simple as possible by applying the following criteria:
このドキュメントでは、以下の基準を適用することにより、情報モデルを可能な限り簡単に保つことを推奨しています。
1. Start with a small set of essential objects and add only as further objects are needed.
1. 必須オブジェクトの小さなセットから始めて、さらなるオブジェクトが必要な場合にのみ追加します。
2. Require that objects be essential for management.
2. オブジェクトが管理に不可欠であることを要求します。
3. Consider evidence of current use and/or utility.
3. 現在の使用および/またはユーティリティの証拠を検討してください。
4. Limit the total number of objects.
4. オブジェクトの総数を制限します。
5. Exclude objects that are simply derivable from others in this or other information models.
5. このモデルまたは他の情報モデルの他の人から単純に派生可能なオブジェクトを除外します。
6. Avoid causing critical sections to be heavily instrumented. A guideline is one counter per critical section per layer.
6. 重要なセクションを重視しないようにしないでください。ガイドラインは、レイヤーごとにクリティカルセクションごとに1つのカウンターです。
The protocol designer should document the basic faults and health indicators that need to be instrumented for the new protocol, as well as the alarms and events that must be propagated to management applications or exposed through a data model.
プロトコル設計者は、新しいプロトコルのために計装する必要がある基本的な障害と健康指標、ならびに管理アプリケーションに伝播したり、データモデルを介して公開したりする必要があるアラームとイベントを文書化する必要があります。
The protocol designer should consider how fault information will be propagated. Will it be done using asynchronous notifications or polling of health indicators?
プロトコル設計者は、障害情報がどのように伝播されるかを検討する必要があります。非同期通知または健康指標のポーリングを使用して行われますか？
If notifications are used to alert operators to certain conditions, then the protocol designer should discuss mechanisms to throttle notifications to prevent congestion and duplications of event notifications. Will there be a hierarchy of faults, and will the fault reporting be done by each fault in the hierarchy, or will only the lowest fault be reported and the higher levels be suppressed? Should there be aggregated status indicators based on concatenation of propagated faults from a given domain or device? SNMP notifications and syslog messages can alert an operator when an aspect of the new protocol fails or encounters an error or failure condition, and SNMP is frequently used as a heartbeat monitor. Should the event reporting provide guaranteed accurate delivery of the event information within a given (high) margin of confidence? Can we poll the latest events in the box?
通知が特定の条件をオペレーターに警告するために使用される場合、プロトコル設計者は、イベント通知の混雑と重複を防ぐために、通知をスロットルするメカニズムについて話し合う必要があります。障害の階層があり、障害の報告は階層の各障害によって行われますか、それとも最低障害のみが報告され、より高いレベルが抑制されますか？特定のドメインまたはデバイスからの伝播された障害の連結に基づいて、集約されたステータスインジケーターが必要ですか？SNMP通知とSyslogメッセージは、新しいプロトコルの側面がエラーまたは障害条件に遭遇した場合、またはSNMPがハートビートモニターとして頻繁に使用される場合、オペレーターに警告することができます。イベントレポートは、特定の（高い）信頼マージン内のイベント情報の保証された正確な配信を提供する必要がありますか？箱の中の最新のイベントを投票できますか？
Protocol designers should always build in basic testing features (e.g., ICMP echo, UDP/TCP echo service, NULL RPCs (remote procedure calls)) that can be used to test for liveness, with an option to enable and disable them.
プロトコル設計者は、常に基本的なテスト機能（ICMPエコー、UDP/TCPエコーサービス、NULL RPCS（リモート手順呼び出し））を常に構築する必要があります。
Mechanisms for monitoring the liveness of the protocol and for detecting faults in protocol connectivity are usually built into protocols. In some cases, mechanisms already exist within other protocols responsible for maintaining lower-layer connectivity (e.g., ICMP echo), but often new procedures are required to detect failures and to report rapidly, allowing remedial action to be taken.
プロトコルの活性を監視し、プロトコル接続の障害を検出するためのメカニズムは、通常、プロトコルに組み込まれています。場合によっては、低レイヤーの接続性の維持（ICMPエコーなど）を維持する原因となる他のプロトコル内にメカニズムが既に存在しますが、多くの場合、障害を検出し、迅速に報告するために新しい手順が必要であり、是正措置を講じることができます。
These liveness monitoring mechanisms do not typically require additional management capabilities. However, when a system detects a fault, there is often a requirement to coordinate recovery action through management applications or at least to record the fact in an event log.
これらの責任モニタリングメカニズムは、通常、追加の管理機能を必要としません。ただし、システムが障害を検出すると、管理アプリケーションを通じて回復アクションを調整するか、少なくともイベントログに事実を記録する必要があることがよくあります。
It can be helpful to describe how faults can be pinpointed using management information. For example, counters might record instances of error conditions. Some faults might be able to be pinpointed by comparing the outputs of one device and the inputs of another device, looking for anomalies. Protocol designers should consider what counters should count. If a single counter provided by vendor A counts three types of error conditions, while the corresponding counter provided by vendor B counts seven types of error conditions, these counters cannot be compared effectively -- they are not interoperable counters.
管理情報を使用して障害を特定できる方法を説明することは役立ちます。たとえば、カウンターはエラー条件のインスタンスを記録する場合があります。あるデバイスの出力と別のデバイスの入力を比較して、異常を探すことにより、いくつかの障害を特定できる場合があります。プロトコル設計者は、カウンターをカウントすべきかを考慮する必要があります。ベンダーAが提供する単一のカウンターが3種類のエラー条件をカウントし、ベンダーBから提供される対応するカウンターが7種類のエラー条件をカウントする場合、これらのカウンターを効果的に比較することはできません - 相互運用可能なカウンターではありません。
How do you distinguish between faulty messages and good messages?
故障したメッセージと良いメッセージをどのように区別しますか？
Would some threshold-based mechanisms, such as Remote Monitoring (RMON) events/alarms or the EVENT-MIB, be usable to help determine error conditions? Are SNMP notifications for all events needed, or are there some "standard" notifications that could be used? Or can relevant counters be polled as needed?
リモート監視（RMON）イベント/アラームやイベント-MIBなどの一部のしきい値ベースのメカニズムは、エラー条件を決定するのに役立つでしょうか？必要なすべてのイベントのSNMP通知は、使用できる「標準」通知がありますか？または、関連するカウンターを必要に応じてポーリングできますか？
Root cause analysis is about working out where in the network the fault is. For example, if end-to-end data delivery is failing (reported by a notification), root cause analysis can help find the failed link or node in the end-to-end path.
根本原因分析とは、ネットワーク内の障害がどこにあるかを策定することです。たとえば、エンドツーエンドのデータ配信が失敗した場合（通知によって報告されています）、根本原因分析は、エンドツーエンドパスで失敗したリンクまたはノードを見つけるのに役立ちます。
It might be useful to isolate or quarantine faults, such as isolating a device that emits malformed messages that are necessary to coordinate connections properly. This might be able to be done by configuring next-hop devices to drop the faulty messages to prevent them from entering the rest of the network.
接続を適切に調整するために必要な不正なメッセージを放出するデバイスを分離するなど、断層を分離または検疫することは有用かもしれません。これは、次のホップデバイスを構成して故障したメッセージをドロップして、ネットワークの残りの部分に入るのを防ぐことで実行できる場合があります。
A protocol designer should document the basic configuration parameters that need to be instrumented for a new protocol, as well as default values and modes of operation.
プロトコル設計者は、新しいプロトコルのために計装する必要がある基本的な構成パラメーター、およびデフォルト値と操作モードを文書化する必要があります。
What information should be maintained across reboots of the device, or restarts of the management system?
デバイスの再起動、または管理システムの再起動でどのような情報を維持する必要がありますか？
"Requirements for Configuration Management of IP-based Networks" [RFC3139] discusses requirements for configuration management, including discussion of different levels of management, high-level policies, network-wide configuration data, and device-local configuration. Network configuration is not just multi-device push or pull. It is knowing that the configurations being pushed are semantically compatible. Is the circuit between them configured compatibly on both ends? Is the IS-IS metric the same? ... Now answer those questions for 1,000 devices.
「IPベースのネットワークの構成管理の要件」[RFC3139]は、さまざまなレベルの管理、高レベルのポリシー、ネットワーク全体の構成データ、デバイスローカル構成の議論など、構成管理の要件について説明します。ネットワーク構成は、マルチデバイスのプッシュまたはプルだけではありません。プッシュされる構成が意味的に互換性があることを知っています。それらの間の回路は両端で互換性のある構成されていますか？IS-ISメトリックは同じですか？...次に、1,000のデバイスの質問に答えます。
A number of efforts have existed in the IETF to develop policy-based configuration management. "Terminology for Policy-Based Management" [RFC3198] was written to standardize the terminology across these efforts.
IETFには、ポリシーベースの構成管理を開発するための多くの取り組みが存在しています。「政策ベースの管理の用語」[RFC3198]は、これらの取り組みにわたって用語を標準化するために書かれました。
Implementations should not arbitrarily modify configuration data. In some cases (such as access control lists (ACLs)), the order of data items is significant and comprises part of the configured data. If a protocol designer defines mechanisms for configuration, it would be desirable to standardize the order of elements for consistency of configuration and of reporting across vendors and across releases from vendors.
実装は、構成データを任意に変更しないでください。場合によっては（アクセス制御リスト（ACLS）など）、データ項目の順序は重要であり、構成されたデータの一部で構成されます。プロトコルデザイナーが構成のメカニズムを定義する場合、構成の一貫性とベンダー間のレポート、およびベンダーからのリリース全体の要素の順序を標準化することが望ましいでしょう。
There are two parts to this:
これには2つの部分があります。
1. A Network Management System (NMS) could optimize ACLs for performance reasons.
1. ネットワーク管理システム（NMS）は、パフォーマンス上の理由でACLを最適化できます。
2. Unless the device/NMS systems has correct rules / a lot of experience, reordering ACLs can lead to a huge security issue.
2. デバイス / NMSシステムに正しいルール /多くの経験がない限り、ACLを並べ替えると大きなセキュリティの問題が発生する可能性があります。
Network-wide configurations may be stored in central master databases and transformed into formats that can be pushed to devices, either by generating sequences of CLI commands or complete configuration files that are pushed to devices. There is no common database schema for network configuration, although the models used by various operators are probably very similar. Many operators consider it desirable to extract, document, and standardize the common parts of these network-wide configuration database schemas. A protocol designer should consider how to standardize the common parts of configuring the new protocol, while recognizing that vendors may also have proprietary aspects of their configurations.
ネットワーク全体の構成は、中央マスターデータベースに保存され、CLIコマンドのシーケンスを生成するか、デバイスにプッシュされた完全な構成ファイルを生成することにより、デバイスにプッシュできる形式に変換される場合があります。さまざまな演算子が使用するモデルはおそらく非常に似ていますが、ネットワーク構成には一般的なデータベーススキーマはありません。多くのオペレーターは、これらのネットワーク全体の構成データベーススキーマの共通部分を抽出、文書化、および標準化することが望ましいと考えています。プロトコル設計者は、新しいプロトコルの構成の一般的な部分を標準化する方法を検討し、ベンダーも構成の独自の側面を持っている可能性があることを認識する必要があります。
It is important to enable operators to concentrate on the configuration of the network as a whole, rather than individual devices. Support for configuration transactions across a number of devices could significantly simplify network configuration management. The ability to distribute configurations to multiple devices, or to modify candidate configurations on multiple devices, and then activate them in a near-simultaneous manner might help. Protocol designers can consider how it would make sense for their protocol to be configured across multiple devices. Configuration templates might also be helpful.
オペレーターが個々のデバイスではなく、ネットワーク全体の構成に集中できるようにすることが重要です。多くのデバイスでの構成トランザクションのサポートは、ネットワーク構成管理を大幅に簡素化する可能性があります。構成を複数のデバイスに配布したり、複数のデバイスで候補構成を変更したり、ほぼ同時にアクティブ化する機能が役立つ場合があります。プロトコル設計者は、プロトコルが複数のデバイスで構成されることがどのように意味を持つかを考慮することができます。構成テンプレートも役立つ場合があります。
Consensus of the 2002 IAB Workshop [RFC3535] was that textual configuration files should be able to contain international characters. Human-readable strings should utilize UTF-8, and protocol elements should be in case-insensitive ASCII.
2002年のIABワークショップ[RFC3535]のコンセンサスは、テキスト構成ファイルが国際的なキャラクターを含めることができるはずだということでした。人間の読み取り可能な文字列は、UTF-8を利用する必要があり、プロトコル要素はケースに依存しないASCIIである必要があります。
A mechanism to dump and restore configurations is a primitive operation needed by operators. Standards for pulling and pushing configurations from/to devices are desirable.
構成をダンプして復元するメカニズムは、オペレーターが必要とする原始操作です。デバイスから、およびデバイスへの構成を引くとプッシュするための標準が望ましい。
Given configuration A and configuration B, it should be possible to generate the operations necessary to get from A to B with minimal state changes and effects on network and systems. It is important to minimize the impact caused by configuration changes.
構成Aと構成Bを与えられている場合、ネットワークとシステムの状態の変更と影響を最小限に抑えて、AからBからBを取得するために必要な操作を生成することが可能である必要があります。構成の変更によって引き起こされる影響を最小限に抑えることが重要です。
A protocol designer should consider the configurable items that exist for the control of function via the protocol elements described in the protocol specification. For example, sometimes the protocol requires that timers can be configured by the operator to ensure specific policy-based behavior by the implementation. These timers should have default values suggested in the protocol specification and may not need to be otherwise configurable.
プロトコル設計者は、プロトコル仕様で説明されているプロトコル要素を介して機能の制御のために存在する構成可能なアイテムを考慮する必要があります。たとえば、プロトコルでは、実装により特定のポリシーベースの動作を確保するために、オペレーターがタイマーを構成できる場合があります。これらのタイマーは、プロトコル仕様で提案されているデフォルト値を持つ必要があり、そうでなければ構成可能である必要がない場合があります。
An important function that should be provided is guidance on how to verify the correct operation of a protocol. A protocol designer could suggest techniques for testing the impact of the protocol on the network before it is deployed as well as techniques for testing the effect that the protocol has had on the network after being deployed.
提供されるべき重要な機能は、プロトコルの正しい操作を検証する方法に関するガイダンスです。プロトコル設計者は、ネットワークが展開する前にプロトコルの影響をテストするための手法と、プロトコルが展開後にネットワークに与えた効果をテストする手法を提案できます。
Protocol designers should consider how to test the correct end-to-end operation of the service or network, how to verify the correct functioning of the protocol, and whether that is verified by testing the service function and/or by testing the forwarding function of each network element. This may be achieved through status and statistical information gathered from devices.
プロトコル設計者は、サービスまたはネットワークの正しいエンドツーエンド操作をテストする方法、プロトコルの正しい機能を検証する方法、およびサービス機能のテストまたは/または転送機能のテストによって検証されるかどうかを検討する必要があります。各ネットワーク要素。これは、デバイスから収集されたステータスと統計情報によって達成される場合があります。
A protocol designer should consider whether it would be appropriate to collect usage information related to this protocol and, if so, what usage information would be appropriate to collect.
プロトコル設計者は、このプロトコルに関連する使用情報を収集することが適切かどうか、およびその場合、どの使用情報が収集するのに適しているかを検討する必要があります。
"Introduction to Accounting Management" [RFC2975] discusses a number of factors relevant to monitoring usage of protocols for purposes of capacity and trend analysis, cost allocation, auditing, and billing. The document also discusses how some existing protocols can be used for these purposes. These factors should be considered when designing a protocol whose usage might need to be monitored or when recommending a protocol to do usage accounting.
「会計管理の紹介」[RFC2975]は、容量と傾向分析、コスト割り当て、監査、請求の目的でプロトコルの使用の監視に関連する多くの要因について説明しています。このドキュメントでは、これらの目的に既存のプロトコルを使用する方法についても説明しています。これらの要因は、使用法を監視する必要があるプロトコルを設計するとき、または使用会計を実行するためにプロトコルを推奨するときに考慮する必要があります。
From a manageability point of view, it is important to determine how well a network deploying the protocol or technology defined in the document is doing. In order to do this, the network operators need to consider information that would be useful to determine the performance characteristics of a deployed system using the target protocol.
管理可能性の観点から、ドキュメントで定義されているプロトコルまたはテクノロジーを展開するネットワークがどれだけうまく機能しているかを判断することが重要です。これを行うには、ネットワークオペレーターは、ターゲットプロトコルを使用して展開されたシステムのパフォーマンス特性を決定するのに役立つ情報を考慮する必要があります。
The IETF, via the Benchmarking Methodology WG (BMWG), has defined recommendations for the measurement of the performance characteristics of various internetworking technologies in a laboratory environment, including the systems or services that are built from these technologies. Each benchmarking recommendation describes the class of equipment, system, or service being addressed; discusses the performance characteristics that are pertinent to that class; clearly identifies a set of metrics that aid in the description of those characteristics; specifies the methodologies required to collect said metrics; and lastly, presents the requirements for the common, unambiguous reporting of benchmarking results. Search for "benchmark" in the RFC search tool.
IETFは、ベンチマーク方法論WG（BMWG）を介して、これらのテクノロジーから構築されたシステムやサービスを含む実験室環境でのさまざまなインターネットワークテクノロジーのパフォーマンス特性の測定に関する推奨事項を定義しています。各ベンチマークの推奨事項は、対処されている機器、システム、またはサービスのクラスについて説明しています。そのクラスに関連するパフォーマンス特性について説明します。これらの特性の説明を支援する一連のメトリックを明確に識別します。上記のメトリックを収集するために必要な方法論を指定します。そして最後に、ベンチマーク結果の一般的で明確な報告の要件を提示します。RFC検索ツールで「ベンチマーク」を検索します。
Performance metrics may be useful in multiple environments and for different protocols. The IETF, via the IP Performance Monitoring (IPPM) WG, has developed a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics are designed such that they can be performed by network operators, end users, or independent testing groups. The existing metrics might be applicable to the new protocol. Search for "metric" in the RFC search tool. In some cases, new metrics need to be defined. It would be useful if the protocol documentation identified the need for such new metrics. For performance monitoring, it is often important to report the time spent in a state, rather than reporting the current state. Snapshots are of less value for performance monitoring.
パフォーマンスメトリックは、複数の環境や異なるプロトコルで役立つ場合があります。IETFは、IPパフォーマンス監視（IPPM）WGを介して、インターネットデータ配信サービスの品質、パフォーマンス、信頼性に適用できる標準メトリックのセットを開発しました。これらのメトリックは、ネットワークオペレーター、エンドユーザー、または独立したテストグループが実行できるように設計されています。既存のメトリックは、新しいプロトコルに適用される場合があります。RFC検索ツールで「メトリック」を検索します。場合によっては、新しいメトリックを定義する必要があります。プロトコルのドキュメントがこのような新しいメトリックの必要性を特定した場合に役立ちます。パフォーマンス監視の場合、現在の状態を報告するのではなく、州で費やされた時間を報告することがしばしば重要です。スナップショットは、パフォーマンス監視の価値が低くなります。
There are several parts to performance management to be considered: protocol monitoring, device monitoring (the impact of the new protocol / service activation on the device), network monitoring, and service monitoring (the impact of service activation on the network).
パフォーマンス管理には、プロトコルの監視、デバイスの監視（デバイスに対する新しいプロトコル /サービスのアクティベーションの影響）、ネットワーク監視、およびサービス監視（ネットワーク上のサービスアクティベーションの影響）など、いくつかの部分があります。
Certain properties of protocols are useful to monitor. The number of protocol packets received, the number of packets sent, and the number of packets dropped are usually very helpful to operators.
プロトコルの特定の特性は、監視するのに役立ちます。受信したプロトコルパケットの数、送信されるパケットの数、ドロップされたパケットの数は、通常、オペレーターに非常に役立ちます。
Packet drops should be reflected in counter variable(s) somewhere that can be inspected -- both from the security point of view and from the troubleshooting point of view.
パケットドロップは、セキュリティの観点からもトラブルシューティングの観点からも、検査できるカウンター変数に反映される必要があります。
Counter definitions should be unambiguous about what is included in the count and what is not included in the count.
カウンターの定義は、カウントに含まれているものとカウントに含まれていないものについて明確でなければなりません。
Consider the expected behaviors for counters -- what is a reasonable maximum value for expected usage? Should they stop counting at the maximum value and retain the maximum value, or should they rollover? How can users determine if a rollover has occurred, and how can users determine if more than one rollover has occurred? Consider whether multiple management applications will share a counter; if so, then no one management application should be allowed to reset the value to zero since this will impact other applications.
カウンターの予想される動作を考慮してください - 予想される使用の合理的な最大値は何ですか？最大値でカウントを停止し、最大値を保持する必要がありますか、それともロールオーバーする必要がありますか？ユーザーは、ロールオーバーが発生したかどうかをどのように判断でき、ユーザーは複数のロールオーバーが発生したかどうかをどのように判断できますか？複数の管理アプリケーションがカウンターを共有するかどうかを検討してください。その場合、他のアプリケーションに影響を与えるため、1つの管理アプリケーションをゼロにリセットすることは許可されません。
Could events, such as hot-swapping a blade in a chassis, cause discontinuities in counter? Does this make any difference in evaluating the performance of a protocol?
シャーシでブレードをホットスワッピングするなどのイベントは、カウンターに不連続性を引き起こす可能性がありますか？これは、プロトコルのパフォーマンスの評価に違いをもたらしますか？
The protocol document should make clear the limitations implicit within the protocol and the behavior when limits are exceeded. This should be considered in a data-modeling-independent manner -- what makes managed-protocol sense, not what makes management-protocol-sense. If constraints are not managed-protocol-dependent, then it should be left for the management-protocol data modelers to decide. For example, VLAN identifiers have a range of 1..4095 because of the VLAN standards. A MIB implementing a VLAN table should be able to support 4096 entries because the content being modeled requires it.
プロトコル文書は、プロトコル内の暗黙の制限と制限を超えたときの動作を明確にする必要があります。これは、データモデリングに依存しない方法で考慮する必要があります。これは、管理プロトコルを意味するものではなく、マネージドプロトコルを意味するものではありません。制約が管理されていない場合、プロトコルに依存していない場合は、Management-Protocol Data Modelersが決定する必要があります。たとえば、VLANの識別子の範囲は、VLAN標準のために1..4095の範囲です。MIBがVLANテーブルを実装するには、モデル化されているコンテンツに必要なため、4096エントリをサポートできる必要があります。
Consider whether device performance will be affected by the number of protocol entities being instantiated on the device. Designers of an information model should include information, accessible at runtime, about the maximum number of instances an implementation can support, the current number of instances, and the expected behavior when the current instances exceed the capacity of the implementation or the capacity of the device.
デバイスのパフォーマンスが、デバイスにインスタンス化されているプロトコルエンティティの数によって影響を受けるかどうかを検討してください。情報モデルの設計者には、実行時にアクセス可能な情報、実装がサポートできるインスタンスの最大数、現在のインスタンス数、および現在のインスタンスがデバイスの実装容量または容量を超える場合の予想される動作についての情報を含める必要があります。。
Designers of an information model should model information, accessible at runtime, about the maximum number of protocol entity instances an implementation can support on a device, the current number of instances, and the expected behavior when the current instances exceed the capacity of the device.
情報モデルの設計者は、実行時にアクセス可能な情報をモデル化する必要があります。プロトコルエンティティインスタンスの最大数のインスタンスは、実装がデバイス、現在のインスタンス数、および現在のインスタンスがデバイスの容量を超える場合の予想される動作でサポートできます。
Consider whether network performance will be affected by the number of protocol entities being deployed.
ネットワークパフォーマンスが展開されているプロトコルエンティティの数によって影響を受けるかどうかを検討してください。
Consider the capability of determining the operational activity, such as the number of messages in and the messages out, the number of received messages rejected due to format problems, and the expected behaviors when a malformed message is received.
メッセージの数やメッセージの数、フォーマットの問題により拒否されたメッセージの数、および奇形のメッセージが受信されたときの予想される動作など、運用アクティビティを決定する能力を考慮してください。
What are the principal performance factors that need to be looked at when measuring the operational performance of the network built using the protocol? Is it important to measure setup times? End-to-end connectivity? Hop-to-hop connectivity? Network throughput?
プロトコルを使用して構築されたネットワークの運用パフォーマンスを測定するときに検討する必要がある主要なパフォーマンス要因は何ですか？セットアップ時間を測定することが重要ですか？エンドツーエンドの接続？ホップツーホップ接続？ネットワークスループット？
What are the principal performance factors that need to be looked at when measuring the performance of a service using the protocol? Is it important to measure application-specific throughput? Client-server associations? End-to-end application quality? Service interruptions? User experience?
プロトコルを使用してサービスのパフォーマンスを測定するときに検討する必要がある主要なパフォーマンス要因は何ですか？アプリケーション固有のスループットを測定することが重要ですか？クライアントサーバー協会？エンドツーエンドのアプリケーション品質？サービスの中断？ユーザー体験？
Protocol designers should consider how to monitor and manage security aspects and vulnerabilities of the new protocol.
プロトコル設計者は、新しいプロトコルのセキュリティの側面と脆弱性を監視および管理する方法を検討する必要があります。
There will be security considerations related to the new protocol. To make it possible for operators to be aware of security-related events, it is recommended that system logs should record events, such as failed logins, but the logs must be secured.
新しいプロトコルに関連するセキュリティ上の考慮事項があります。オペレーターがセキュリティ関連のイベントを認識できるようにするには、システムログが失敗したログインなどのイベントを記録することをお勧めしますが、ログは保護する必要があります。
Should a system automatically notify operators of every event occurrence, or should an operator-defined threshold control when a notification is sent to an operator?
システムは、すべてのイベントが発生することをオペレーターに自動的に通知する必要がありますか、それとも通知がオペレーターに送信されたときにオペレーターが定義するしきい値制御を制御する必要がありますか？
Should certain statistics be collected about the operation of the new protocol that might be useful for detecting attacks, such as the receipt of malformed messages, messages out of order, or messages with invalid timestamps? If such statistics are collected, is it important to count them separately for each sender to help identify the source of attacks?
不正なメッセージの受信、順序のないメッセージ、または無効なタイムスタンプを持つメッセージなどの攻撃を検出するのに役立つ可能性のある新しいプロトコルの操作について特定の統計を収集する必要がありますか？そのような統計が収集されている場合、攻撃の原因を特定するために、各送信者について個別に数えることが重要ですか？
Manageability considerations that are security-oriented might include discussion of the security implications when no monitoring is in place, the regulatory implications of absence of audit-trail or logs in enterprises, exceeding the capacity of logs, and security exposures present in chosen/recommended management mechanisms.
セキュリティ指向の管理可能性の考慮事項には、監視が行われていない場合のセキュリティへの影響、企業における監査トレイルの欠如またはログの規制上の意味、ログの能力を超える、および選択/推奨管理に存在するセキュリティエクスポージャーが含まれる場合があります。メカニズム。
Consider security threats that may be introduced by management operations. For example, Control and Provisioning of Wireless Access Points (CAPWAP) breaks the structure of monolithic Access Points (APs) into Access Controllers and Wireless Termination Points (WTPs). By using a management interface, internal information that was previously not accessible is now exposed over the network and to management applications and may become a source of potential security threats.
管理業務によって導入される可能性のあるセキュリティの脅威を検討してください。たとえば、ワイヤレスアクセスポイント（CAPWAP）の制御とプロビジョニングは、モノリシックアクセスポイント（AP）の構造をアクセスコントローラーとワイヤレス終了ポイント（WTP）に分割します。管理インターフェイスを使用することにより、以前にアクセスできない内部情報がネットワークおよび管理アプリケーションに公開され、潜在的なセキュリティの脅威のソースになる可能性があります。
The granularity of access control needed on management interfaces needs to match operational needs. Typical requirements are a role-based access control model and the principle of least privilege, where a user can be given only the minimum access necessary to perform a required task.
管理インターフェイスで必要なアクセス制御の粒度は、運用上のニーズに合う必要があります。典型的な要件は、役割ベースのアクセス制御モデルと、ユーザーに必要なタスクを実行するために必要な最小アクセスのみを与えることができる最小特権の原則です。
Some operators wish to do consistency checks of access control lists across devices. Protocol designers should consider information models to promote comparisons across devices and across vendors to permit checking the consistency of security configurations.
一部のオペレーターは、デバイス間でアクセス制御リストの一貫性チェックを行いたいと考えています。プロトコル設計者は、デバイスとベンダー間の比較を促進する情報モデルを検討して、セキュリティ構成の一貫性をチェックすることを許可する必要があります。
Protocol designers should consider how to provide a secure transport, authentication, identity, and access control that integrates well with existing key and credential management infrastructure. It is a good idea to start with defining the threat model for the protocol, and from that deducing what is required.
プロトコル設計者は、既存のキーおよび資格管理インフラストラクチャとうまく統合する安全なトランスポート、認証、ID、およびアクセス制御を提供する方法を検討する必要があります。プロトコルの脅威モデルを定義することと、必要なものを推測することから始めることをお勧めします。
Protocol designers should consider how access control lists are maintained and updated.
プロトコル設計者は、アクセス制御リストの維持と更新方法を検討する必要があります。
Standard SNMP notifications or syslog messages [RFC5424] might already exist, or can be defined, to alert operators to the conditions identified in the security considerations for the new protocol. For example, you can log all the commands entered by the operator using syslog (giving you some degree of audit trail), or you can see who has logged on/off using the Secure SHell Protocol (SSH) and from where; failed SSH logins can be logged using syslog, etc.
標準のSNMP通知またはSyslogメッセージ[RFC5424]は、新しいプロトコルのセキュリティに関する考慮事項で特定された条件を演算子に警告するために、すでに存在するか、定義することができます。たとえば、Syslogを使用してオペレーターが入力したすべてのコマンドをログに記録することができます（ある程度の監査証跡を与える）、またはSecure Shell Protocol（SSH）とどこからログオン/オフをログオンした人を確認できます。失敗したSSHログインは、Syslogなどを使用してログに記録できます。
An analysis of existing counters might help operators recognize the conditions identified in the security considerations for the new protocol before they can impact the network.
既存のカウンターの分析は、オペレーターがネットワークに影響を与える前に、新しいプロトコルのセキュリティに関する考慮事項で特定された条件を認識するのに役立つ場合があります。
Different management protocols use different assumptions about message security and data-access controls. A protocol designer that recommends using different protocols should consider how security will be applied in a balanced manner across multiple management interfaces. SNMP authority levels and policy are data-oriented, while CLI authority levels and policy are usually command-oriented (i.e., task-oriented). Depending on the management function, sometimes data-oriented or task-oriented approaches make more sense. Protocol designers should consider both data-oriented and task-oriented authority levels and policy.
さまざまな管理プロトコルは、メッセージセキュリティとデータアクセス制御に関するさまざまな仮定を使用します。異なるプロトコルの使用を推奨するプロトコル設計者は、複数の管理インターフェイスでバランスの取れた方法でセキュリティを適用する方法を検討する必要があります。SNMPの権限レベルとポリシーはデータ指向であり、CLIの権限レベルとポリシーは通常、コマンド指向（つまり、タスク指向）です。管理機能に応じて、データ指向またはタスク指向のアプローチがより理にかなっています。プロトコル設計者は、データ指向の権限レベルとタスク指向の権限レベルとポリシーの両方を考慮する必要があります。
This document is focused on what a protocol designer should think about and how those considerations might be documented.
このドキュメントは、プロトコル設計者が考えるべきこと、およびそれらの考慮事項がどのように文書化されるかに焦点を当てています。
This document does not describe interoperability requirements but rather describes practices that are useful to follow when dealing with manageability aspects in IETF documents, so the capitalized keywords from [RFC2119] do not apply here. Any occurrence of words like 'must' or 'should' needs to be interpreted only in the context of their natural, English-language meaning.
このドキュメントでは、相互運用性の要件を説明するのではなく、IETFドキュメントの管理可能性の側面を扱うときに従うのに役立つプラクティスについて説明するため、[RFC2119]の大文字のキーワードはここには適用されません。「必須」や「すべき」などの単語の発生は、自然な英語の意味の文脈でのみ解釈する必要があります。
A Manageability Considerations section should include discussion of the management and operations topics raised in this document, and when one or more of these topics is not relevant, it would be useful to contain a simple statement explaining why the topic is not relevant for the new protocol. Of course, additional relevant topics should be included as well.
管理可能性の考慮事項セクションには、このドキュメントで提起された管理と運用のトピックの議論を含める必要があります。これらのトピックの1つが関連しない場合、このトピックが新しいプロトコルに関連しない理由を説明する簡単なステートメントを含めることが有用です。もちろん、追加の関連トピックも含める必要があります。
Existing protocols and data models can provide the management functions identified in the previous section. Protocol designers should consider how using existing protocols and data models might impact network operations.
既存のプロトコルとデータモデルは、前のセクションで特定された管理機能を提供できます。プロトコル設計者は、既存のプロトコルとデータモデルの使用がネットワーク操作にどのように影響するかを検討する必要があります。
A protocol designer may seriously consider the manageability requirements of a new protocol and determine that no management functionality is needed by the new protocol. It would be helpful to those who may update or write extensions to the protocol in the future or to those deploying the new protocol to know the thinking of the working group regarding the manageability of the protocol at the time of its design.
プロトコル設計者は、新しいプロトコルの管理可能性要件を真剣に検討し、新しいプロトコルで管理機能が必要ないと判断する場合があります。将来のプロトコルを更新または書き込み、新しいプロトコルを展開して、その設計時のプロトコルの管理性に関するワーキンググループの思考を知ることができる人に役立ちます。
If there are no new manageability or deployment considerations, it is recommended that a Manageability Considerations section contain a simple statement such as, "There are no new manageability requirements introduced by this document," and a brief explanation of why that is the case. The presence of such a Manageability Considerations section would indicate to the reader that due consideration has been given to manageability and operations.
新しい管理可能性または展開に関する考慮事項がない場合は、「このドキュメントによって導入された新しい管理可能性要件はありません」などの簡単なステートメントや、その理由の簡単な説明などの簡単なステートメントを含めることをお勧めします。このような管理可能性に関する考慮事項の存在セクションは、管理可能性と運用に適切な考慮が与えられていることを読者に示します。
In the case where the new protocol is an extension and the base protocol discusses all the relevant operational and manageability considerations, it would be helpful to point out the considerations section in the base document.
新しいプロトコルが拡張機能であり、基本プロトコルが関連するすべての運用および管理性の考慮事項について説明する場合、ベースドキュメントの考慮事項セクションを指摘することをお勧めします。
If a protocol designer develops a Manageability Considerations section for a new protocol, it is recommended that the section be placed immediately before the Security Considerations section. Reviewers interested in such sections could find it easily, and this placement could simplify the development of tools to detect the presence of such a section.
プロトコル設計者が新しいプロトコルの管理可能性に関する考慮事項セクションを開発する場合、セクションをセキュリティに関する考慮事項の直前に配置することをお勧めします。そのようなセクションに興味のあるレビューアはそれを簡単に見つけることができ、この配置はそのようなセクションの存在を検出するツールの開発を簡素化することができます。
This document is informational and provides guidelines for considering manageability and operations. It introduces no new security concerns.
このドキュメントは情報提供であり、管理性と運用を検討するためのガイドラインを提供します。新しいセキュリティの懸念は導入されません。
The provision of a management portal to a network device provides a doorway through which an attack on the device may be launched. Making the protocol under development be manageable through a management protocol creates a vulnerability to a new source of attacks. Only management protocols with adequate security apparatus, such as authentication, message integrity checking, and authorization, should be used.
ネットワークデバイスへの管理ポータルの提供は、デバイスへの攻撃が起動する可能性のある出入り口を提供します。開発中のプロトコルを管理プロトコルを介して管理しやすくすると、新しい攻撃ソースに対する脆弱性が生まれます。認証、メッセージの整合性チェック、承認など、適切なセキュリティ装置を持つ管理プロトコルのみを使用する必要があります。
A standard description of the manageable knobs and whistles on a protocol makes it easier for an attacker to understand what they may try to control and how to tweak it.
プロトコル上の管理可能なノブとホイッスルの標準的な説明により、攻撃者は自分が何を制御しようとし、どのように調整するかを理解しやすくなります。
A well-designed protocol is usually more stable and secure. A protocol that can be managed and inspected offers the operator a better chance of spotting and quarantining any attacks. Conversely, making a protocol easy to inspect is a risk if the wrong person inspects it.
よく設計されたプロトコルは、通常、より安定して安全です。管理および検査できるプロトコルは、オペレーターに攻撃を見つけて検疫する可能性が高くなります。逆に、プロトコルを検査しやすいものにすることは、間違った人がそれを検査する場合、リスクです。
If security events cause logs and/or notifications/alerts, a concerted attack might be able to be mounted by causing an excess of these events. In other words, the security-management mechanisms could constitute a security vulnerability. The management of security aspects is important (see Section 3.7).
セキュリティイベントがログおよび/または通知/アラートを引き起こす場合、これらのイベントの過剰を引き起こすことにより、協調的な攻撃を取り付けることができる可能性があります。言い換えれば、セキュリティ管理メカニズムはセキュリティの脆弱性を構成する可能性があります。セキュリティの側面の管理は重要です（セクション3.7を参照）。
This document started from an earlier document edited by Adrian Farrel, which itself was based on work exploring the need for Manageability Considerations sections in all Internet-Drafts produced within the Routing Area of the IETF. That earlier work was produced by Avri Doria, Loa Andersson, and Adrian Farrel, with valuable feedback provided by Pekka Savola and Bert Wijnen.
このドキュメントは、Adrian Farrelが編集した以前のドキュメントから始まりました。それ自体は、IETFのルーティングエリア内で作成されたすべてのインターネットドラフトの管理可能性に関する考慮事項セクションの必要性を調査する作業に基づいていました。その以前の作品は、Avri Doria、Loa Andersson、およびAdrian Farrelによってプロデュースされ、Pekka SavolaとBert Wijnenが提供する貴重なフィードバックを提供しました。
Some of the discussion about designing for manageability came from private discussions between Dan Romascanu, Bert Wijnen, Juergen Schoenwaelder, Andy Bierman, and David Harrington.
管理可能性のための設計に関する議論のいくつかは、ダン・ロマスカヌ、バート・ウィジネン、ジュエルゲン・シェーンワールダー、アンディ・ビアマン、デビッド・ハリントンの間の個人的な議論から来ました。
Thanks to reviewers who helped fashion this document, including Harald Alvestrand, Ron Bonica, Brian Carpenter, Benoit Claise, Adrian Farrel, David Kessens, Dan Romascanu, Pekka Savola, Juergen Schoenwaelder, Bert Wijnen, Ralf Wolter, and Lixia Zhang.
Harald Alvestrand、Ron Bonica、Brian Carpenter、Benoit Claise、Adrian Farrel、David Kessens、Dan Romascanu、Pekka Savola、Juergen Schoenwaelder、Bert Wijnen、Ralf Wolter、Lixia Zhangなど、この文書の作成を手伝ったレビュアーに感謝します。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1052] Cerf, V., "IAB recommendations for the development of Internet network management standards", RFC 1052, April 1988.
[RFC1052] Cerf、V。、「インターネットネットワーク管理標準の開発に関するIABの推奨」、RFC 1052、1988年4月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]カーペンター、B。、「インターネットの建築原理」、RFC 1958、1996年6月。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113] Katz、D。、「IPルーターアラートオプション」、RFC 2113、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205] Braden、B.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[RFC2439] Villamizar、C.、Chandra、R。、およびR. Govindan、「BGP Route Flap Damping」、RFC 2439、1998年11月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711] Partridge、C。およびA. Jackson、「IPv6ルーターアラートオプション」、RFC 2711、1999年10月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[RFC2975] Aboba、B.、Arkko、J。、およびD. Harrington、「会計管理の紹介」、RFC 2975、2000年10月。
[RFC3060] Moore, B., Ellesson, E., Strassner, J., and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[RFC3060] Moore、B.、Ellesson、E.、Strassner、J。、およびA. Westerinen、「ポリシーコア情報モデル - バージョン1仕様」、RFC 3060、2001年2月。
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[RFC3084] Chan、K.、Seligson、J.、Durham、D.、Gai、S.、McCloghrie、K.、Herzog、S.、Reichmeyer、F.、Yavatkar、R。、およびA. Smith、「警官」ポリシープロビジョニングの使用（COPS-PR） "、RFC 3084、2001年3月。
[RFC3139] Sanchez, L., McCloghrie, K., and J. Saperia, "Requirements for Configuration Management of IP-based Networks", RFC 3139, June 2001.
[RFC3139] Sanchez、L.、McCloghrie、K。、およびJ. Saperia、「IPベースのネットワークの構成管理の要件」、RFC 3139、2001年6月。
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[RFC3198] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、J。、およびS。Waldbusser、「政策ベースの管理の用語」、RFC 3198、2001年11月。
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.
[RFC3290] Bernet、Y.、Blake、S.、Grossman、D。、およびA. Smith、「Diffservルーターの非公式管理モデル」、RFC 3290、2002年5月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410] Case、J.、Mundy、R.、Partain、D。、およびB. Stewart、「インターネット標準管理フレームワークの紹介と適用声明」、RFC 3410、2002年12月。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003.
[RFC3444] Pras、A。およびJ. Schoenwaelder、「情報モデルとデータモデルの違いについて」、RFC 3444、2003年1月。
[RFC3460] Moore, B., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003.
[RFC3460]ムーア、B。、「ポリシーコア情報モデル（PCIM）拡張機能」、RFC 3460、2003年1月。
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003.
[RFC3535] Schoenwaelder、J。、「2002 IAB Network Management Workshopの概要」、RFC 3535、2003年5月。
[RFC3585] Jason, J., Rafalow, L., and E. Vyncke, "IPsec Configuration Policy Information Model", RFC 3585, August 2003.
[RFC3585] Jason、J.、Rafalow、L。、およびE. Vyncke、「IPSEC構成ポリシー情報モデル」、RFC 3585、2003年8月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「直径ベースプロトコル」、RFC 3588、2003年9月。
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R., and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003.
[RFC3644] Snir、Y.、Ramberg、Y.、Strassner、J.、Cohen、R。、およびB. Moore、「Policy of Service（QoS）情報モデル」、RFC 3644、2003年11月。
[RFC3670] Moore, B., Durham, D., Strassner, J., Westerinen, A., and W. Weiss, "Information Model for Describing Network Device QoS Datapath Mechanisms", RFC 3670, January 2004.
[RFC3670] Moore、B.、Durham、D.、Strassner、J.、Westerinen、A。、およびW. Weiss、「ネットワークデバイスQoSデータパスメカニズムを説明するための情報モデル」、RFC 3670、2004年1月。
[RFC3805] Bergman, R., Lewis, H., and I. McDonald, "Printer MIB v2", RFC 3805, June 2004.
[RFC3805] Bergman、R.、Lewis、H。、およびI. McDonald、「Printer Mib V2」、RFC 3805、2004年6月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] ENNS、R。、「NetConf Configuration Protocol」、RFC 4741、2006年12月。
[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[RFC5321] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5424] Gerhards、R。、「Syslog Protocol」、RFC 5424、2009年3月。
[W3C.REC-xmlschema-0-20010502] Fallside, D., "XML Schema Part 0: Primer", World Wide Web Consortium FirstEdition REC-xmlschema-0-20010502, May 2001, <http://www.w3.org/TR/2001/REC-xmlschema-0-20010502>.
[W3C.REC-XMLSCHEMA-0-20010502]フォールサイド、D。、「XMLスキーマパート0：プライマー」、World Wide Web Consortium Firstedition REC-XMLSchema-0-20010502、2001年5月<http：//www.w3。ORG/TR/2001/REC-XMLSCHEMA-0-20010502>。
This appendix provides a quick checklist of issues that protocol designers should expect operations and management expert reviewers to look for when reviewing a document being proposed for consideration as a protocol standard.
この付録には、プロトコル設計者がプロトコル標準として検討するために提案されているドキュメントをレビューする際に、オペレーションおよび管理の専門家レビュアーが探すことを期待する問題の簡単なチェックリストを提供します。
1. Has deployment been discussed? See Section 2.1.
1. 展開について議論されましたか？セクション2.1を参照してください。
* Does the document include a description of how this protocol or technology is going to be deployed and managed?
* このドキュメントには、このプロトコルまたはテクノロジーがどのように展開および管理されるかについての説明が含まれていますか？
* Is the proposed specification deployable? If not, how could it be improved?
* 提案された仕様は展開できますか？そうでない場合、どうすれば改善できますか？
* Does the solution scale well from the operational and management perspective? Does the proposed approach have any scaling issues that could affect usability for large-scale operation?
* ソリューションは、運用および管理の観点から十分に拡大していますか？提案されたアプローチには、大規模な操作のユーザビリティに影響を与える可能性のあるスケーリングの問題がありますか？
* Are there any coexistence issues?
* 共存の問題はありますか？
2. Has installation and initial setup been discussed? See Section 2.2.
2. インストールと初期セットアップについて説明しましたか？セクション2.2を参照してください。
* Is the solution sufficiently configurable?
* ソリューションは十分に構成できますか？
* Are configuration parameters clearly identified?
* 構成パラメーターは明確に識別されていますか？
* Are configuration parameters normalized?
* 構成パラメーターは正規化されていますか？
* Does each configuration parameter have a reasonable default value?
* 各構成パラメーターには妥当なデフォルト値がありますか？
* Will configuration be pushed to a device by a configuration manager, or pulled by a device from a configuration server?
* 構成は、構成マネージャーによってデバイスにプッシュされますか、それとも構成サーバーからデバイスによって引っ張られますか？
* How will the devices and managers find and authenticate each other?
* デバイスとマネージャーはどのようにお互いを見つけて認証しますか？
3. Has the migration path been discussed? See Section 2.3.
3. 移行パスについて議論されましたか？セクション2.3を参照してください。
* Are there any backward compatibility issues?
* 後方互換性の問題はありますか？
4. Have the Requirements on other protocols and functional components been discussed? See Section 2.4.
4. 他のプロトコルや機能コンポーネントの要件について説明しましたか？セクション2.4を参照してください。
* What protocol operations are expected to be performed relative to the new protocol or technology, and what protocols and data models are expected to be in place or recommended to ensure for interoperable management?
* 新しいプロトコルまたはテクノロジーに関連して実行されるプロトコル操作は、どのプロトコルとデータモデルが導入可能な管理を確保するために導入または推奨されると予想されるものですか？
5. Has the impact on network operation been discussed? See Section 2.5.
5. ネットワーク操作への影響について議論されましたか？セクション2.5を参照してください。
* Will the new protocol significantly increase traffic load on existing networks?
* 新しいプロトコルは、既存のネットワークのトラフィック負荷を大幅に増加させますか？
* Will the proposed management for the new protocol significantly increase traffic load on existing networks?
* 新しいプロトコルの提案された管理は、既存のネットワークのトラフィック負荷を大幅に増加させるでしょうか？
* How will the new protocol impact the behavior of other protocols in the network? Will it impact performance (e.g., jitter) of certain types of applications running in the same network?
* 新しいプロトコルは、ネットワーク内の他のプロトコルの動作にどのように影響しますか？同じネットワークで実行されている特定のタイプのアプリケーションのパフォーマンス（ジッターなど）に影響を与えますか？
* Does the new protocol need supporting services (e.g., DNS or Authentication, Authorization, and Accounting - AAA) added to an existing network?
* 新しいプロトコルには、既存のネットワークに追加されたサポートサービス（DNSまたは認証、認証、会計-AAAなど）が必要ですか？
6. Have suggestions for verifying correct operation been discussed? See Section 2.6.
6. 正しい操作を確認するための提案が議論されましたか？セクション2.6を参照してください。
* How can one test end-to-end connectivity and throughput?
* エンドツーエンドの接続とスループットをどのようにテストできますか？
* Which metrics are of interest?
* どのメトリックが興味深いですか？
* Will testing have an impact on the protocol or the network?
* テストはプロトコルまたはネットワークに影響を与えますか？
7. Has management interoperability been discussed? See Section 3.1.
7. 管理の相互運用性は議論されていますか？セクション3.1を参照してください。
* Is a standard protocol needed for interoperable management?
* 相互運用可能な管理には標準プロトコルが必要ですか？
* Is a standard information or data model needed to make properties comparable across devices from different vendors?
* さまざまなベンダーのデバイス間でプロパティを比較可能にするために標準的な情報またはデータモデルが必要ですか？
8. Are there fault or threshold conditions that should be reported? See Section 3.3.
8. 報告すべき障害またはしきい値条件はありますか？セクション3.3を参照してください。
* Does specific management information have time utility?
* 特定の管理情報には時間のユーティリティがありますか？
* Should the information be reported by notifications? Polling? Event-driven polling?
* 情報は通知によって報告されるべきですか？ポーリング？イベント主導のポーリング？
* Is notification throttling discussed?
* 通知は議論されていますか？
* Is there support for saving state that could be used for root cause analysis?
* 根本原因分析に使用できる状態を節約するためのサポートはありますか？
9. Is configuration discussed? See Section 3.4.
9. 構成は議論されていますか？セクション3.4を参照してください。
* Are configuration defaults and default modes of operation considered?
* 構成のデフォルトとデフォルトの操作モードは考慮されていますか？
* Is there discussion of what information should be preserved across reboots of the device or the management system? Can devices realistically preserve this information through hard reboots where physical configuration might change (e.g., cards might be swapped while a chassis is powered down)?
* デバイスまたは管理システムの再起動全体でどの情報を保存すべきかについての議論はありますか？デバイスは、物理的な構成が変更される可能性のあるハードリブートを通じてこの情報を現実的に保存できます（たとえば、シャーシが電源を入れている間にカードが交換される可能性があります）？
Do you anticipate any manageability issues with the specification?
仕様に関する管理可能性の問題が予想されますか？
1. Is management interoperability discussed? See Section 3.1.
1. 管理の相互運用性は説明されていますか？セクション3.1を参照してください。
* Will it use centralized or distributed management?
* 集中または分散型管理を使用しますか？
* Will it require remote and/or local management applications?
* リモートおよび/またはローカル管理アプリケーションが必要ですか？
* Are textual or graphical user interfaces required?
* テキストまたはグラフィカルなユーザーインターフェイスが必要ですか？
* Is textual or binary format for management information preferred?
* 管理情報のテキスト形式またはバイナリ形式は望ましいですか？
2. Is management information discussed? See Section 3.2.
2. 管理情報は議論されていますか？セクション3.2を参照してください。
* What is the minimal set of management (configuration, faults, performance monitoring) objects that need to be instrumented in order to manage the new protocol?
* 新しいプロトコルを管理するために計装する必要がある管理の最小セット（構成、障害、パフォーマンス監視）オブジェクトは何ですか？
3. Is fault management discussed? See Section 3.3.
3. 障害管理は議論されていますか？セクション3.3を参照してください。
* Is Liveness Detection and Monitoring discussed?
* liveness livensionの検出と監視は説明されていますか？
* Does the solution have failure modes that are difficult to diagnose or correct? Are faults and alarms reported and logged?
* ソリューションには、診断または修正が困難な障害モードがありますか？障害とアラームは報告され、記録されていますか？
4. Is configuration management discussed? See Section 3.4.
4. 構成管理は議論されていますか？セクション3.4を参照してください。
* Is protocol state information exposed to the user? How? Are significant state transitions logged?
* プロトコル状態情報はユーザーにさらされていますか？どうやって？重要な状態移行は記録されていますか？
5. Is accounting management discussed? See Section 3.5.
5. 会計管理は議論されていますか？セクション3.5を参照してください。
6. Is performance management discussed? See Section 3.6.
6. パフォーマンス管理は議論されていますか？セクション3.6を参照してください。
* Does the protocol have an impact on network traffic and network devices? Can performance be measured?
* プロトコルはネットワークトラフィックとネットワークデバイスに影響を与えますか？パフォーマンスを測定できますか？
* Is protocol performance information exposed to the user?
* プロトコルのパフォーマンス情報はユーザーにさらされていますか？
7. Is security management discussed? See Section 3.7.
7. セキュリティ管理は議論されていますか？セクション3.7を参照してください。
* Does the specification discuss how to manage aspects of security, such as access controls, managing key distribution, etc.
* 仕様では、アクセス制御、主要な分布の管理など、セキュリティの側面を管理する方法について説明します。
Is an operational considerations and/or manageability section part of the document?
運用上の考慮事項および/または管理性セクションは、ドキュメントの一部ですか？
Does the proposed protocol have a significant operational impact on the Internet?
提案されたプロトコルは、インターネットに大きな運用上の影響を与えますか？
Is there proof of implementation and/or operational experience?
実装および/または運用経験の証明はありますか？
Author's Address
著者の連絡先
David Harrington HuaweiSymantec USA 20245 Stevens Creek Blvd Cupertino, CA 95014 USA
David Harrington Huaweisymantec USA 20245 STEVENS CREEK BLVD CUPERTINO、CA 95014 USA
Phone: +1 603 436 8634
EMail: ietfdbh@comcast.net