[要約] RFC 6123は、PCE Working Groupのドラフトに管理可能性セクションを含めることを目的としています。このRFCの目的は、PCEプロトコルの管理可能性に関する情報を提供し、実装者や運用者に役立つガイドラインを提供することです。
Internet Engineering Task Force (IETF) A. Farrel
Request for Comments: 6123 Old Dog Consulting
Category: Historic February 2011
ISSN: 2070-1721
Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts
パス計算要素（PCE）ワーキンググループドラフトに管理可能性セクションを含める
Abstract
概要
It has often been the case that manageability considerations have been retrofitted to protocols after they have been specified, standardized, implemented, or deployed. This is sub-optimal. Similarly, new protocols or protocol extensions are frequently designed without due consideration of manageability requirements.
多くの場合、管理可能性の考慮事項が、指定、標準化、実装、または展開された後、プロトコルに改装された場合があります。これは最適です。同様に、新しいプロトコルまたはプロトコル拡張は、管理可能性の要件を十分に考慮せずに頻繁に設計されます。
The Operations Area has developed "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions" (RFC 5706), and those guidelines have been adopted by the Path Computation Element (PCE) Working Group.
オペレーション領域は、「新しいプロトコルとプロトコル拡張の運用と管理を検討するためのガイドライン」（RFC 5706）を開発し、それらのガイドラインはPath計算要素（PCE）ワーキンググループによって採用されています。
Previously, the PCE Working Group used the recommendations contained in this document to guide authors of Internet-Drafts on the contents of "Manageability Considerations" sections in their work. This document is retained for historic reference.
以前は、PCEワーキンググループは、このドキュメントに含まれる推奨事項を使用して、作業中の「管理可能性に関する考慮事項」セクションの内容に関するインターネットドラフトの著者を導きました。このドキュメントは、歴史的な参照のために保持されています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントは、インターネット標準の追跡仕様ではありません。歴史的記録のために公開されています。
This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティ向けの歴史的なドキュメントを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6123.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6123で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 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 Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document is produced for historic reference.
このドキュメントは、歴史的な参照のために作成されています。
When new protocols or protocol extensions are developed, it is often the case that not enough consideration is given to the manageability of the protocols or to the way in which they will be operated in the network. The result is that manageability considerations are only understood once the protocols have been implemented and sometimes not until after they have been deployed.
新しいプロトコルまたはプロトコル拡張が開発されると、プロトコルの管理性やネットワークでの動作方法について十分な考慮が与えられていないことがよくあります。その結果、管理性の考慮事項は、プロトコルが実装された後にのみ理解され、時には展開されるまでは理解されません。
The resultant attempts to retrofit manageability mechanisms are not always easy or architecturally pleasant. Furthermore, it is possible that certain protocol designs make manageability particularly hard to achieve.
マネージャビリティメカニズムを改装しようとする試みは、必ずしも容易であるとは限りません。さらに、特定のプロトコル設計により、管理性が特に達成が難しくなる可能性があります。
Recognizing that manageability is fundamental to the utility and success of protocols designed within the IETF, and that simply defining a MIB module does not necessarily provide adequate manageability, this document was developed to define recommendations for the inclusion of Manageability Considerations sections in all Internet-Drafts produced within the PCE Working Group. It was the intention that meeting these recommendations would ensure that proper consideration was given to the support of manageability at all stages of the protocol development process from Requirements and Architecture through Specification and Applicability.
管理可能性はIETF内で設計されたプロトコルの有用性と成功の基本であり、MIBモジュールを単に定義するだけでは適切な管理性を提供するわけではないことを認識することで、このドキュメントは、すべてのインターネットドラフトに管理可能性の考慮事項セクションを含めるための推奨事項を定義するために開発されました。PCEワーキンググループ内で生産されます。これらの推奨事項を満たすことにより、プロトコル開発プロセスのすべての段階で、要件とアーキテクチャから仕様と適用可能性を介した管理プロセスの管理可能性のサポートが適切に考慮されることが保証されることが意図されていました。
It is clear that the presence of such a section in an Internet-Draft does not guarantee that the protocol will be well-designed or manageable. However, the inclusion of this section will ensure that the authors have the opportunity to consider the issues, and, by reading the material in this document, they will gain some guidance.
インターネットドラフトにそのようなセクションが存在することは、プロトコルが適切に設計または管理可能であることを保証しないことは明らかです。ただし、このセクションを含めることで、著者が問題を検討する機会があることを保証し、この文書の資料を読むことにより、彼らはいくつかのガイダンスを得るでしょう。
This document was developed within the PCE Working Group and was used to help guide the authors and editors within the working group to produce Manageability Considerations sections in the Internet-Drafts and RFCs produced by the working group.
このドキュメントは、PCEワーキンググループ内で開発され、ワーキンググループ内の著者と編集者をガイドするために使用され、ワーキンググループが作成したインターネットドラフトとRFCで管理可能性に関する考慮事項セクションを作成しました。
[RFC5706] presents general guidance from the IETF's Operations Area for considering Operations and Management of new protocols and protocol extensions. It has been adopted by the PCE Working Group to provide guidance to editors and authors within the working group, so this document is no longer required. However, the working group considers that it will be useful to archive this document as Historic for future reference.
[RFC5706]は、新しいプロトコルとプロトコル拡張の運用と管理を検討するためのIETFの運用エリアからの一般的なガイダンスを提示します。ワーキンググループ内の編集者や著者にガイダンスを提供するためにPCEワーキンググループによって採用されているため、このドキュメントは不要になりました。ただし、ワーキンググループは、このドキュメントを将来の参照のために歴史的なものとしてアーカイブすることが有用であると考えています。
This document is not a protocol specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] in order that the contents of a Manageability Considerations section can be clearly understood.
このドキュメントはプロトコル仕様ではありません。「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]で説明されているように解釈されるため、マネジービリティ考慮事項セクションの内容を明確に理解できるようにします。
In this context, "manageability" is used to refer to the interactions between a network operator (a human or an application) and the network components (hosts, routers, switches, applications, and protocols) performed to ensure the correct operation of the network.
このコンテキストでは、「管理可能性」は、ネットワークの正しい動作を確保するために実行されたネットワークオペレーター（ヒューマンまたはアプリケーション）とネットワークコンポーネント（ホスト、ルーター、スイッチ、アプリケーション、およびプロトコル）の間の相互作用を参照するために使用されます。。
Manageability issues are often referred to under the collective acronym, FCAPS [X.700], which stands for the following:
管理可能性の問題は、多くの場合、集合的な頭字語FCAPS [X.700]で言及されます。
- Fault management - Configuration - Accounting - Performance - Security
- 障害管理 - 構成 - 会計 - パフォーマンス - セキュリティ
Conventionally, Security is already covered an Internet-Draft in its own Security Considerations section, and this document does not in any way diminish the need for that section. Indeed, as pointed out in Section 6, a full consideration of other aspects of manageability may increase the text that should be supplied in the Security Considerations section.
従来、セキュリティは既にインターネットドラフトを独自のセキュリティ上の考慮事項セクションでカバーしていますが、このドキュメントでは、そのセクションの必要性を決して減少させません。実際、セクション6で指摘されているように、管理可能性の他の側面を完全に考慮すると、セキュリティに関する考慮事項セクションで提供されるべきテキストが増加する可能性があります。
The author of a Manageability Considerations section should certainly consider all aspects of FCAPS. The author should reflect on how the manageability of a new protocol impacts the manageability and operation of the entire network. Specific optional subsections (see Section 2.3) should be added as necessary to describe features of FCAPS that are pertinent but are not covered by the recommended subsections. More discussion of what manageability is and what may be included in a Manageability Considerations section can be found in [RFC5706].
管理可能性に関する考慮事項の著者は、FCAPのすべての側面を確実に考慮する必要があります。著者は、新しいプロトコルの管理性がネットワーク全体の管理性と動作にどのように影響するかを考える必要があります。特定のオプションのサブセクション（セクション2.3を参照）は、関連するが推奨サブセクションではカバーされていないFCAPの機能を説明するために必要に応じて追加する必要があります。管理性とは何か、および管理性に関する考慮事項に含まれる可能性のあるものについての詳細については、[RFC5706]に記載されています。
As part of documenting the manageability considerations for a new protocol or for protocol extensions, authors should consider that one of the objectives of specifying protocols within the IETF is to ensure interoperability of implementations. This interoperability extends to the manageability function so that it is an ideal that there should be implementation independence between management applications and managed entities. This may be promoted by the use of standardized management protocols and by the specification of standard information models.
新しいプロトコルまたはプロトコル拡張の管理可能性に関する考慮事項を文書化する一環として、著者は、IETF内のプロトコルを指定する目的の1つは、実装の相互運用性を確保することであると考える必要があります。この相互運用性は、管理アプリケーションとマネージドエンティティの間に実装の独立性があることが理想的であるため、管理可能性関数に拡張されます。これは、標準化された管理プロトコルの使用と標準情報モデルの仕様によって促進される場合があります。
Note that, in some contexts, reference is made to the term "management plane". This is used to describe the exchange of management messages through management protocols (often transported by IP and by IP transport protocols) between management applications and the managed entities such as network nodes. The management plane may use distinct addressing schemes, virtual links or tunnels, or a physically separate management control network. The management plane should be seen as separate from, but possibly overlapping with, the control plane, in which signaling and routing messages are exchanged, and the forwarding plane (sometimes called the data plane or user plane), in which user traffic is transported.
一部のコンテキストでは、「管理面」という用語を参照することに注意してください。これは、管理アプリケーションとネットワークノードなどのマネージドエンティティ間の管理プロトコル（多くの場合、IPおよびIP輸送プロトコルによって輸送されることが多い）を介した管理メッセージの交換を説明するために使用されます。管理プレーンは、異なるアドレス指定スキーム、仮想リンクまたはトンネル、または物理的に個別の管理制御ネットワークを使用する場合があります。管理プレーンは、信号とルーティングメッセージが交換されるコントロールプレーンとは別のが、おそらくオーバーラップし、ユーザートラフィックが輸送される転送面（データプレーンまたはユーザープレーンと呼ばれることもあります）と見なされる必要があります。
Note that examples of the sections described here can be found in the documents listed in Appendix A.
ここで説明するセクションの例は、付録Aにリストされているドキュメントに記載されていることに注意してください。
In the event that there are no manageability requirements for an Internet-Draft, the draft SHOULD still contain a Manageability Considerations section. The presence of this section indicates to the reader that due consideration has been given to manageability and that there are no (or no new) requirements.
インターネットドラフトの管理可能性の要件がない場合、ドラフトにはマネージアビリティに関する考慮事項セクションがまだ含まれている必要があります。このセクションの存在は、読者に、管理可能性に適切な考慮が与えられており、要件がない（または新しい）要件がないことを示しています。
In this case, the section SHOULD contain a simple statement such as "There are no new manageability requirements introduced by this document" and SHOULD briefly explain why that is the case with a summary of manageability mechanisms that already exist.
この場合、セクションには「このドキュメントによって導入された新しい管理可能性要件はありません」などの簡単なステートメントが含まれている必要があり、その理由を簡単に説明する必要があります。
Note that a null Manageability Considerations section may take some effort to compose. It is important to demonstrate to the reader that no additional manageability mechanisms are required, and it is often hard to prove that something is not needed. A null Manageability Considerations section SHOULD NOT consist only of the simple statement that there are no new manageability requirements.
null管理可能性の考慮事項セクションでは、構成するためにある程度の努力が必要になる場合があることに注意してください。追加の管理メカニズムは必要ないことを読者に示すことが重要であり、何かが必要ないことを証明することはしばしば困難です。null管理可能性の考慮事項セクションは、新しい管理可能性の要件がないという単純な声明だけで構成されるべきではありません。
If an Internet-Draft genuinely has no manageability impact, it should be possible to construct a simple null Manageability Considerations section that explains why this is the case.
インターネットドラフトに真に管理可能性の影響がない場合、なぜそうなのかを説明する単純なnull管理性に関する考慮事項セクションを構築することができるはずです。
If the Manageability Considerations section is not null, it SHOULD contain at least the following subsections. Guidance on the content of these subsections can be found in Section 3 of this document.
マネジービリティの考慮事項セクションがnullでない場合、少なくとも次のサブセクションを含める必要があります。これらのサブセクションの内容に関するガイダンスは、このドキュメントのセクション3に記載されています。
- Control of Function through Configuration and Policy - Information and Data Models, e.g., MIB modules - Liveness Detection and Monitoring - Verifying Correct Operation - Requirements on Other Protocols and Functional Components - Impact on Network Operation
- 構成とポリシーによる機能の制御 - 情報とデータモデル、例えばMIBモジュール - 責任検出と監視 - 正しい操作の検証 - 他のプロトコルと機能コンポーネントの要件 - ネットワーク操作への影響
In the event that one or more of these subsections is not relevant, it SHOULD still be present and SHOULD contain a simple statement explaining why the subsection is not relevant. That is, null subsections are allowed, and each should be formed following the advice in Section 2.1.
これらのサブセクションの1つ以上が関連性がない場合、それはまだ存在する必要があり、サブセクションが関連性がない理由を説明する簡単なステートメントを含める必要があります。つまり、ヌルサブセクションは許可されており、セクション2.1のアドバイスに従ってそれぞれを形成する必要があります。
The list of subsections above is not intended to be prescriptively limiting. Other subsections can and SHOULD be added according to the requirements of each individual Internet-Draft. If a topic does not fit comfortably into any of the subsections listed, the authors should be relaxed about adding new subsections as necessary.
上記のサブセクションのリストは、規範的に制限されることを意図したものではありません。他のサブセクションは、個々のインターネットドラフトの要件に従って追加できます。トピックがリストされているサブセクションのいずれにも快適に収まらない場合、著者は必要に応じて新しいサブセクションを追加することについてリラックスする必要があります。
The Manageability Considerations section SHOULD be placed immediately before the Security Considerations section in any Internet-Draft.
マネジービリティに関する考慮事項セクションは、インターネットドラフトのセキュリティに関する考慮事項セクションの直前に配置する必要があります。
This section gives guidance on the information to be included in each of the recommended subsections listed above. Note that, just as other subsections may be included, so additional information MAY also be included in these subsections.
このセクションでは、上記の推奨サブセクションのそれぞれに含まれる情報に関するガイダンスを示します。他のサブセクションが含まれているように、これらのサブセクションにも追加情報が含まれる可能性があることに注意してください。
This subsection describes the functional elements that may be controlled through configuration and/or policy.
このサブセクションでは、構成および/またはポリシーを通じて制御できる機能要素について説明します。
For example, many protocol specifications include timers that are used as part of the operation of the protocol. These timers often have default values suggested in the protocol specification and do not need to be configurable. However, it is often the case that the protocol requires that the timers can be configured by the operator to ensure specific behavior by the implementation.
たとえば、多くのプロトコル仕様には、プロトコルの動作の一部として使用されるタイマーが含まれます。これらのタイマーは、多くの場合、プロトコル仕様で提案されているデフォルト値を持っているため、構成可能である必要はありません。ただし、多くの場合、プロトコルでは、実装による特定の動作を確保するために、オペレーターがタイマーを設定できることが必要です。
Even if all configurable items have been described within the body of the document, they SHOULD be identified in this subsection, but a reference to another section of the document is sufficient if there is a full description elsewhere.
ドキュメントの本文内ですべての構成可能なアイテムが説明されている場合でも、このサブセクションで特定する必要がありますが、他の場所に完全な説明がある場合は、ドキュメントの別のセクションへの参照で十分です。
Other protocol elements are amenable to control through the application of local or network-wide policy. It is not the intention that this subsection should give details of policy implementation since that is covered by more general policy framework specifications such as [RFC3060] and [RFC3460]. Additionally, specific frameworks for policy as applicable within protocol or functional architectures are also normally covered in separate documents, for example, [RFC5394].
他のプロトコル要素は、ローカルまたはネットワーク全体のポリシーを適用することで制御できます。[RFC3060]や[RFC3460]などのより一般的なポリシーフレームワークの仕様でカバーされているため、このサブセクションはポリシーの実装の詳細を提供することを意図していません。さらに、プロトコルまたは機能アーキテクチャ内で該当するポリシーの特定のフレームワークは、通常、別のドキュメント、たとえば[RFC5394]でもカバーされています。
However, this section SHOULD identify which protocol elements are potentially subject to policy and should give guidance on the application of policy for successful operation of the protocol. Where this material is already described within the body of the document, this subsection SHOULD still identify the issues and reference the other sections of the document.
ただし、このセクションでは、どのプロトコル要素がポリシーの対象となるかを特定し、プロトコルの運用を成功させるためのポリシーの適用に関するガイダンスを提供する必要があります。この資料がドキュメントの本文内ですでに説明されている場合、このサブセクションは問題を識別し、ドキュメントの他のセクションを参照する必要があります。
This subsection SHOULD describe the information and data models necessary for the protocol or the protocol extensions. This includes, but is not necessarily limited to, the MIB modules developed specifically for the protocol functions specified in the document.
このサブセクションでは、プロトコルまたはプロトコル拡張に必要な情報とデータモデルを説明する必要があります。これには、ドキュメントで指定されたプロトコル関数専用に開発されたMIBモジュールが含まれますが、必ずしも限定されていません。
Where new or extended MIB modules are recommended, it is helpful if this section can give an overview of the items to be modeled by the MIB modules. This does not require an object-by-object description of all of the information that needs to be modeled, but it could explain the high-level "object groupings" (perhaps to the level of suggesting the MIB tables) and certainly should explain the major manageable entities. For example, a protocol specification might include separate roles for "sender" and "receiver" and might be broken into a "session" and individual "transactions"; if so, this section could list these functionalities as separate manageable entities.
新規または拡張されたMIBモジュールが推奨される場合、このセクションがMIBモジュールによってモデル化されるアイテムの概要を提供できる場合に役立ちます。これには、モデル化する必要があるすべての情報のオブジェクトごとの説明は必要ありませんが、高レベルの「オブジェクトグループ」（おそらくMIBテーブルを提案するレベルまで）を説明でき、確かに説明する必要があります。主要な管理可能なエンティティ。たとえば、プロトコルの仕様には、「送信者」と「受信機」の個別の役割が含まれる場合があり、「セッション」と個別の「トランザクション」に分割される場合があります。その場合、このセクションでは、これらの機能を個別の管理可能なエンティティとしてリストできます。
[RFC3444] may be useful in determining what information to include in this section.
[RFC3444]は、このセクションに含まれる情報を決定するのに役立つ場合があります。
The description in this section can be by reference where other documents already exist.
このセクションの説明は、他のドキュメントが既に存在する場所を参照することができます。
It should be noted that the significance of MIB modules may be decreasing, but there is still a requirement to consider the managed objects necessary for successful operation of the protocol or protocol extensions. This means that due consideration should be given not only to what objects need to be managed but also to what management model should be used. There are now several options, including the MIB/SNMP (Simple Network Management Protocol) model and the Network Configuration Protocol (NETCONF) model, being developed by the NETCONF Data Modeling Language (NETMOD) Working Group [YANG].
MIBモジュールの重要性は減少している可能性があることに注意する必要がありますが、プロトコルまたはプロトコル拡張の操作を成功させるために必要な管理オブジェクトを考慮する必要があります。これは、適切な考慮事項に、どのオブジェクトを管理する必要があるかだけでなく、どの管理モデルを使用すべきかについても、適切に考慮する必要があることを意味します。現在、MIB/SNMP（Simple Network Management Protocol）モデルとネットワーク構成プロトコル（NetConf）モデルを含むいくつかのオプションがあり、NetConf Data Modeling Language（NetMod）ワーキンググループ[Yang]によって開発されています。
Liveness detection and monitoring apply both to the control plane and the data plane.
活性検出と監視は、コントロールプレーンとデータプレーンの両方に適用されます。
Mechanisms for detecting faults in the control plane or for monitoring its liveness are usually built into the control plane protocols or inherited from underlying data plane or forwarding plane protocols. These mechanisms do not typically require additional management capabilities but are essential features for the protocol to be usable and manageable. Therefore, this section SHOULD highlight the mechanisms in the new protocol or protocol extensions that are required in order to ensure liveness detection and monitoring within the protocol.
コントロールプレーンの障害を検出したり、その活性を監視するためのメカニズムは、通常、コントロールプレーンプロトコルに組み込まれたり、基礎となるデータプレーンまたは転送面のプロトコルから継承されたりします。これらのメカニズムは通常、追加の管理機能を必要としませんが、プロトコルが使用可能で管理しやすくするための重要な機能です。したがって、このセクションでは、プロトコル内でのライベン検出と監視を確保するために必要な新しいプロトコルまたはプロトコル拡張のメカニズムを強調する必要があります。
Further, when a control plane fault is detected, there is often a requirement to coordinate recovery action through management applications or at least to record the fact in an event log. This section SHOULD identify the management actions expected when the protocol detects a control plane fault.
さらに、コントロールプレーンの障害が検出されると、管理アプリケーションを通じて回復アクションを調整するか、少なくともイベントログに事実を記録する必要があることがよくあります。このセクションでは、プロトコルがコントロールプレーンの障害を検出したときに予想される管理アクションを特定する必要があります。
Where the protocol is responsible for establishing data or user plane connectivity, liveness detection and monitoring usually need to be achieved through other mechanisms. In some cases, these mechanisms already exist within other protocols responsible for maintaining lower layer connectivity, but it will often be the case that new procedures are required so that failures in the data path can be detected and reported rapidly, allowing remedial action to be taken. This section SHOULD refer to other mechanisms that are assumed to provide monitoring of data plane liveness and SHOULD identify requirements for new mechanisms as appropriate.
プロトコルがデータまたはユーザープレーンの接続を確立する責任がある場合、通常、他のメカニズムを介して活性検出と監視を達成する必要があります。場合によっては、これらのメカニズムはすでに下層の接続性の維持を担当する他のプロトコル内に存在しますが、データパスの障害を迅速に検出および報告できるように、新しい手順が必要になることがよくあります。。このセクションでは、データプレーンの活性の監視を提供すると想定されている他のメカニズムを参照し、必要に応じて新しいメカニズムの要件を特定する必要があります。
This section SHOULD describe the need for liveness and detection monitoring, SHOULD highlight existing tools, SHOULD identify requirements and specifications for new tools (as appropriate for the level of the document being written), and SHOULD describe the coordination of tools with each other, with management applications, and with the base protocol being specified.
このセクションでは、活性と検出の監視の必要性を説明し、既存のツールを強調し、新しいツールの要件と仕様を特定する必要があります（書かれているドキュメントのレベルに適している場合）、ツールの調整を互いに説明する必要があります。管理アプリケーション、および基本プロトコルが指定されています。
An important function that Operations and Management (OAM) can provide is a toolset for verifying the correct operation of a protocol. To some extent, this may be achieved through access to information and data models that report the status of the protocol and the state installed on network devices. However, it may also be valuable to provide techniques for testing the effect that the protocol has had on the network by sending data through the network and observing its behavior.
運用と管理（OAM）が提供できる重要な機能は、プロトコルの正しい動作を検証するためのツールセットです。ある程度、これは、ネットワークデバイスにインストールされているプロトコルと状態のステータスを報告する情報およびデータモデルへのアクセスによって達成される場合があります。ただし、ネットワークを介してデータを送信してその動作を観察することにより、プロトコルがネットワークに与えた効果をテストするための手法を提供することも価値があるかもしれません。
Thus, this section SHOULD include details of how the correct operation of the protocols described by the Internet-Draft can be tested, and, in as far as the Internet-Draft impacts on the operation of the network, this section SHOULD include a discussion about how the correct end-to-end operation of the network can be tested and how the correct data or forwarding plane function of each network element can be verified.
したがって、このセクションには、インターネットドラフトによって説明されているプロトコルの正しい操作をテストする方法の詳細を含める必要があります。また、インターネットドラフトがネットワークの操作に影響する限り、このセクションには説明を含める必要があります。ネットワークの正しいエンドツーエンド操作をテストする方法と、各ネットワーク要素の正しいデータまたは転送平面関数を検証する方法。
There may be some overlap between this section and that describing liveness detection and monitoring since the same tools may be used in some cases.
このセクションと、同じツールが場合によっては使用される可能性があるため、活性の検出と監視を説明するものの間には、ある程度の重複があるかもしれません。
The text in this section SHOULD describe the requirements that the new protocol puts on other protocols and functional components as well as requirements from other protocols that have been considered in designing the new protocol. This is pertinent to manageability because those other protocols may already be deployed and operational and because those other protocols also need to be managed.
このセクションのテキストでは、新しいプロトコルが他のプロトコルと機能コンポーネントに課す要件、および新しいプロトコルの設計で検討されている他のプロトコルからの要件について説明する必要があります。これらの他のプロトコルはすでに展開および動作している可能性があり、他のプロトコルも管理する必要があるため、これは管理可能性に関連しています。
It is not appropriate to consider the interaction between the new protocol and all other protocols in this section, but it is important to identify the specific interactions that are assumed for the correct functioning of the new protocol or protocol extensions.
このセクションの新しいプロトコルと他のすべてのプロトコルとの間の相互作用を考慮することは適切ではありませんが、新しいプロトコルまたはプロトコル拡張の正しい機能について想定される特定の相互作用を特定することが重要です。
The introduction of a new protocol or extensions to an existing protocol may have an impact on the operation of existing networks. This section 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 IGPs operating within the network.
たとえば、ネットワーク内で動作するIGPSのスケーラビリティへの影響に照らして、ネットワーク内で使用されているアクティブでリーチ可能なアドレスの数を2倍にする新しいプロトコルを考慮する必要がある場合があります。
A very important feature that SHOULD be addressed in this section is backward compatibility. If protocol extensions are being introduced, what impact will this have on a network that has an earlier version of the protocol deployed? Will it be necessary to upgrade all nodes in the network? Can the protocol versions operate side by side? Can the new version of the protocol be tunneled through the old version? Can existing services be migrated without causing a traffic hit or is a "maintenance period" required to perform the upgrade? What are the configuration implications for the new and old protocol variants?
このセクションで対処すべき非常に重要な機能は、後方互換性です。プロトコル拡張が導入されている場合、これは以前のバージョンのプロトコルを展開したネットワークにどのような影響を与えますか？ネットワーク内のすべてのノードをアップグレードする必要がありますか？プロトコルバージョンは並んで動作できますか？プロトコルの新しいバージョンを古いバージョンでトンネル化できますか？既存のサービスは、トラフィックヒットを引き起こすことなく移行できますか、それともアップグレードを実行するのに必要な「メンテナンス期間」ですか？新しいプロトコルバリアントと古いプロトコルバリアントの構成への影響は何ですか？
Where a new protocol is introduced, issues similar to backward compatibility may exist and SHOULD be described. How is migration from an old protocol to the new protocol achieved? Do existing protocols need to be interfaced to the new protocol?
新しいプロトコルが導入されている場合、後方互換性と同様の問題が存在する可能性があり、説明する必要があります。古いプロトコルから新しいプロトコルへの移行はどのように達成されますか？既存のプロトコルは新しいプロトコルにインターフェースする必要がありますか？
Anything that is not covered in one of the recommended subsections described above but is needed to understand the manageability situation SHOULD be covered in an additional section. This may be a catch-all section named "Other Considerations" or may be one or more additional optional sections as described in Section 2.3.
上記の推奨サブセクションの1つでカバーされていないが、管理性の状況を理解するために必要なものはすべて、追加セクションでカバーする必要があります。これは、「その他の考慮事項」という名前のキャッチオールセクションである場合もあれば、セクション2.3で説明されているように、1つ以上の追加のオプションセクションである場合もあります。
This document does not introduce any new codepoints or name spaces for registration with IANA. It makes no request to IANA for action.
このドキュメントでは、IANAに登録するための新しいコードポイントや名前スペースは導入されていません。INAにアクションを要求しません。
Internet-Drafts SHOULD NOT introduce new codepoints, name spaces, or requests for IANA action within the Manageability Considerations section.
インターネットドラフトは、管理可能性の考慮事項セクション内で、新しいコードポイント、名前スペース、またはIANAアクションのリクエストを導入すべきではありません。
This document defines Manageability Considerations sections recommended for inclusion in all PCE Working Group Internet-Drafts. As such, the whole document is relevant to manageability.
このドキュメントでは、すべてのPCEワーキンググループインターネットドラフトに含めるために推奨される管理性に関する考慮事項セクションを定義します。そのため、ドキュメント全体は管理性に関連しています。
Note that the impact of the application of this document to Internet-Drafts produced within the PCE Working Group should be that PCE protocols and associated protocols are designed and extended with manageability in mind. This should result in more robust and more easily deployed protocols.
PCEワーキンググループ内で生成されたインターネットドラフトへのこのドキュメントの適用の影響は、PCEプロトコルと関連プロトコルが設計および拡張されていることであることに注意してください。これにより、より堅牢で、より簡単に展開されたプロトコルが発生するはずです。
However, since this document does not describe any specific protocol, protocol extensions, or protocol usage, no manageability considerations need to be discussed here.
ただし、このドキュメントでは特定のプロトコル、プロトコル拡張、またはプロトコルの使用については説明していないため、ここでは管理可能性の考慮事項について説明する必要はありません。
(This is an example of a null Manageability Considerations section).
（これは、null管理可能性の考慮事項セクションの例です）。
This document is Historic and describes the format and content of Internet-Drafts. As such, it introduces no new security concerns.
このドキュメントは歴史的であり、インターネットドラフトの形式とコンテンツについて説明しています。そのため、新しいセキュリティの懸念は導入されません。
However, there is a clear overlap between security, operations, and management. The manageability aspects of security SHOULD be covered within the mandatory Security Considerations of each Internet-Draft. New security considerations introduced by the Manageability Considerations section MUST be covered in the Security Considerations section.
ただし、セキュリティ、運用、および管理の間には明確な重複があります。セキュリティの管理可能性の側面は、各インターネットドラフトの必須のセキュリティ上の考慮事項内でカバーする必要があります。管理可能性に関する考慮事項によって導入された新しいセキュリティに関する考慮事項セクションは、セキュリティに関する考慮事項セクションで説明する必要があります。
Note that fully designing a protocol before it is implemented (including designing the manageability aspects) is likely to result in a more robust protocol. That is a benefit to network security. Retrofitting manageability to a protocol can make the protocol more vulnerable to security attacks, including attacks through the new manageability facilities. Therefore, the use of this document is RECOMMENDED in order to help ensure the security of all protocols to which it is applied.
プロトコルが実装される前に完全に設計する（管理性の側面の設計を含む）、より堅牢なプロトコルになる可能性が高いことに注意してください。これは、ネットワークセキュリティにとって利点です。プロトコルに管理可能性を改装すると、新しい管理施設を介した攻撃など、セキュリティ攻撃に対してプロトコルをより脆弱にすることができます。したがって、このドキュメントの使用は、適用されるすべてのプロトコルのセキュリティを確保するために推奨されます。
This document is based on earlier work exploring the need for Manageability Considerations sections in all Internet-Drafts produced within the Routing Area of the IETF. That document was produced by Avri Doria and Loa Andersson working with the current author. Their input was both sensible and constructive.
このドキュメントは、IETFのルーティングエリア内で生成されたすべてのインターネットドラフトの管理可能性に関する考慮事項セクションの必要性を調査する以前の作業に基づいています。その文書は、Avri DoriaとLoa Anderssonによって現在の著者と協力して作成されました。彼らの入力は賢明で建設的でした。
Peka Savola provided valuable feedback on an early versions of the original document. Thanks to Bert Wijnen, Dan Romascanu, David Harrington, Lou Berger, Spender Dawkins, Tom Petch, Matthew Meyer, Dimitri Papdimitriou, Stewart Bryant, and Jamal Hadi Salim for their comments.
Peka Savolaは、元のドキュメントの初期バージョンに関する貴重なフィードバックを提供しました。Bert Wijnen、Dan Romascanu、David Harrington、Lou Berger、Spender Dawkins、Tom Petch、Matthew Meyer、Dimitri Papdimitriou、Stewart Bryant、Jamal Hadi Salimのコメントに感謝します。
Thanks to the PCE Working Group for adopting the ideas contained in this document and for including Manageability Considerations sections in their Internet-Drafts and RFCs.
このドキュメントに含まれるアイデアを採用してくれたPCEワーキンググループに感謝し、インターネットドラフトとRFCに管理可能性の考慮事項セクションを含めてくれてありがとう。
[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月。
[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月。
[RFC3460] Moore, B., Ed., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003.
[RFC3460] Moore、B.、ed。、「ポリシーコア情報モデル（PCIM）拡張機能」、RFC 3460、2003年1月。
[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月。
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, December 2008.
[RFC5394] Bryskin、I.、Papadimitriou、D.、Berger、L。、およびJ. Ash、「ポリシー対応パス計算フレームワーク」、RFC 5394、2008年12月。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5706] Harrington、D。、「新しいプロトコルとプロトコル拡張の運用と管理を検討するためのガイドライン」、RFC 5706、2009年11月。
[X.700] CCITT Recommendation X.700 (1992), Management framework for Open Systems Interconnection (OSI) for CCITT applications.
[X.700] CCITT推奨X.700（1992）、CCITTアプリケーションのオープンシステム相互接続（OSI）の管理フレームワーク。
[YANG] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010.
[Yang] Bjorklund、M.、ed。、「Yang-ネットワーク構成プロトコル（NetConf）のデータモデリング言語」、RFC 6020、2010年10月。
Readers are referred to the following documents for example Manageability Considerations sections that received positive comments during IESG review:
読者は、IESGレビュー中に肯定的なコメントを受け取った管理性に関する考慮事項など、次のドキュメントを参照してください。
Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
Farrel、A.、Vasseur、J.P。、およびJ. Ash、「パス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、2006年8月。
Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
Le Roux、J.、ed。、「Path Computation Element（PCE）Discoveryの要件」、RFC 4674、2006年10月。
Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
Le Roux、Jl。、ed。、Vasseur、JP。、ed。、Ikejiri、Y。、およびR. Zhang、「Path Computation Element（PCE）DiscoveryのOSPFプロトコル拡張」、RFC 5088、2008年1月。
Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
Vasseur、jp。、ed。、およびJl。Le Roux、ed。、「パス計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、2009年3月。
Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
Bradford、R.、Ed。、Vasseur、JP。、およびA. Farrel、「パスキーベースのメカニズムを使用したドメイン間パス計算のトポロジの機密性の保存」、RFC 5520、2009年4月。
Oki, E., Takeda, T., Le Roux, JL., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering", RFC 5623, September 2009.
Oki、E.、Takeda、T.、Le Roux、Jl。、およびA. Farrel、「PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのフレームワーク」、RFC 5623、2009年9月。
Author's Address
著者の連絡先
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk