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
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）「を新しいプロトコルやプロトコル拡張の運用と管理を考えるためのガイドライン」を開発し、これらのガイドラインは、経路計算エレメント（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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この文書では、プロトコル仕様ではありません。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります管理性の考慮事項セクションの内容が明確に理解できるようにするために、[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.
従来、セキュリティはすでに独自のSecurity Considerations部でのインターネットドラフトに覆われており、この文書は、どのような方法で、そのセクションの必要性を減少させません。第6節で指摘したように確かに、管理性の他の態様の完全な検討事項は、Security Considerations部に供給されなければならないテキストを増大させることができます。
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
管理性の考慮事項セクションの作者は確かにFCAPSのすべての側面を考慮する必要があります。著者は、新しいプロトコルへの影響、ネットワーク全体の管理性と操作の方法を管理に反映する必要があります。特定のオプションのサブセクション（参照
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].
2.3節）が適切ですが、お勧めのサブセクションでカバーされていないFCAPSの機能を説明するために、必要に応じて追加する必要があります。のより多くの議論どの管理され、どのような管理機能の考慮事項のセクションに含めることができる[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内のプロトコルを指定の目的の一つは、実装の相互運用性を確保するためであることを考慮すべきです。管理アプリケーションと管理エンティティ間の実装の独立性がなければならないことが理想的であるように、この相互運用性は、管理機能を拡張します。これは、標準化された管理プロトコルの使用により、標準情報モデルの仕様によって促進させることができます。
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.
インターネットドラフトのための管理要件が存在しないことをイベントでは、草案はまだ管理性の考慮事項のセクションを含むべきです。この節の存在は考慮が管理するとNO（または新しい）の要件がないことを説明したが、読者に示します。
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.
ヌル管理性の考慮事項のセクションでは、構成するいくつかの努力がかかることがあります。追加の管理メカニズムが必要とされていないことを読者に示すために重要であり、何かが必要とされないことを証明することは困難です。ヌル管理性の考慮事項のセクションには、新たな管理要件が存在しないことだけの簡単な声明で構成するべきではありません。
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.
インターネットドラフトは本当に何も管理性への影響を持っていない場合は、そうである理由を説明する簡単なヌルの管理性の考慮事項のセクションを構築することが可能でなければなりません。
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.
サブセクションのリストは、上記prescriptively限定することを意図していません。他のサブセクションでは、各個々のインターネットドラフトの要件に応じて添加されるべきであることができます。トピックがリストされたサブセクションのいずれにも快適にフィットしない場合は、著者は、必要に応じて新しいサブセクションを追加する方法について緩和すべきです。
The Manageability Considerations section SHOULD be placed immediately before the Security Considerations section in any Internet-Draft.
管理性の考慮事項のセクションには、任意のインターネットドラフトでのSecurity Considerations部の直前に配置する必要があります。
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モジュールの重要性が減少することができることに留意すべきであるが、プロトコルまたはプロトコルの拡張機能が正常に動作するために必要な管理オブジェクトを検討する必要性が依然としてあります。これは十分な配慮がないオブジェクトのみを管理することがなく、どのような管理モデルを使用する必要があるために必要なものに与えられるべきであることを意味しています。 NETCONFデータモデリング言語（NETMOD）ワーキンググループ[YANG]によって開発されているMIB / SNMP（簡易ネットワーク管理プロトコル）のモデルとネットワーク構成プロトコル（NETCONF）モデル、など、いくつかのオプションは、今があります。
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.
たとえば、ネットワーク内での使用に積極的に、到達可能なアドレスの数を倍増新しいプロトコルは、ネットワーク内で動作するのIGPのスケーラビリティへの影響の観点から検討する必要があります。
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.
上述の推奨サブセクションのいずれかで覆われていないが、管理の状況を把握するために必要とされるものは、追加のセクションでカバーされるべきです。これは、「その他の考慮事項」という名前のキャッチオールセクションであってもよいか、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の登録のために、新しいコードポイントまたは名前空間を導入しません。これは、アクションのためのIANAへのリクエストを行いません。
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).
（これはヌル管理性Considerations部の一例です）。
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.
しかし、セキュリティ、運用、および管理の間に明確な重複があります。セキュリティの管理の側面は、各インターネットドラフトの必須セキュリティの考慮事項の中にカバーされるべきです。管理性の考慮事項のセクションで導入された新しいセキュリティ上の考慮事項は、Security Considerations部で覆われている必要があります。
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ドリアとロア・アンダーソンは現在、著者と協力して作成しました。彼らの入力は賢明かつ建設的でもありました。
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は、元のドキュメントの初期バージョンの貴重なフィードバックを提供します。彼らのコメントについてバートWijnen、ダンRomascanu、デヴィッド・ハリントン、ルー・バーガー、スペンダードーキンス、トム・ペッチ、マシュー・マイヤー、ディミトリPapdimitriou、スチュワートブライアント、及びジャマル・ハディサリムに感謝します。
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.
この文書に含まれるアイデアを採用すると、彼らのインターネットドラフトやRFCで管理性の考慮事項のセクションを含むためPCEワーキンググループに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ムーア、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]ムーア、B.、エド。、 "方針コア情報モデル（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.、バーガー、L.、およびJ.アッシュ、 "政策対応の経路計算フレームワーク"、RFC 5394、2008年12月。
[RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009.
[RFC5706]ハリントン、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.、エド、 "YANG - ネットワーク構成プロトコルのためのデータモデリング言語（NETCONF）"、RFC 6020、2010年10月。
Appendix A. Example Manageability Considerations Sections
付録A.例管理性の考慮事項セクション
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.
ファレル、A.、Vasseur、J.-P.、およびJ.アッシュ、 "パス計算要素（PCE）ベースのアーキテクチャ"、RFC 4655、2006年8月。
Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
ル・ルー、J.、エド。、RFC 4674、2006年10月 "経路計算エレメント（PCE）の発見のための要件"。
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.
ル・ルー、JL。、エド。、Vasseur、JP。、エド。、池尻、Y.、およびR.張、 "OSPFプロトコル拡張パスの計算要素（PCE）ディスカバリー"、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。、エド。、およびJL。ル・ルー、エド。、 "パス計算要素（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.
ブラッドフォード、R.、エド。、Vasseur、JP。、およびA.ファレル、「パス・キー・ベースのメカニズムを使用したドメイン間の経路計算で保存トポロジ機密性」、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.
沖、E.、武田、T.、ル・ルー、JL。、およびA.ファレル、 "PCEベースの層間MPLSおよびGMPLSトラフィックエンジニアリングのための枠組み"、RFC 5623、2009年9月。
Author's Address
著者のアドレス
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk