[要約] RFC 6684は、IODEFの拡張を定義するためのガイドラインとテンプレートです。その目的は、セキュリティインシデントの情報交換を効率化し、相互運用性を向上させることです。
Internet Engineering Task Force (IETF) B. Trammell
Request for Comments: 6684 ETH Zurich
Category: Informational July 2012
ISSN: 2070-1721
Guidelines and Template for Defining Extensions to the Incident Object Description Exchange Format (IODEF)
インシデントオブジェクト記述交換フォーマット（IODEF）の拡張を定義するためのガイドラインとテンプレート
Abstract
概要
This document provides guidelines for extensions to the Incident Object Description Exchange Format (IODEF) described in RFC 5070 for exchange of incident management data, and it contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions.
このドキュメントは、RFC 5070で説明されているインシデントオブジェクト記述交換フォーマット（IODEF）への拡張に関するインシデント管理データの交換に関するガイドラインを提供し、作業を容易にし、品質を向上させるために、これらの拡張を説明するインターネットドラフト用のテンプレートを含みます拡張機能の説明。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc6684.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6684で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Applicability of Extensions to IODEF ............................3
3. Selecting a Mechanism for IODEF Extension .......................3
4. Security Considerations .........................................5
5. Acknowledgments .................................................5
6. References ......................................................5
6.1. Normative References .......................................5
6.2. Informative References .....................................5
Appendix A. Document Template ......................................7
A.1. Introduction ................................................7
A.2. Terminology .................................................7
A.3. Applicability ...............................................7
A.4. Extension Definition ........................................8
A.5. Security Considerations .....................................8
A.6. IANA Considerations .........................................9
A.7. Manageability Considerations ...............................10
A.8. Appendix A: XML Schema Definition for Extension ............10
A.9. Appendix B: Examples .......................................10
Appendix B. Example Enumerated Type Extension Definition:
Presentation Action ...................................10
Appendix C. Example Element Definition: Test ......................10
In the five years since the specification of IODEF [RFC5070], the threat environment has evolved, as has the practice of cooperative network defense. These trends, along with experience gained through implementation and deployment, have indicated the need to extend IODEF. This document provides guidelines for defining these extensions. It starts by describing the applicability of IODEF extensions, and the IODEF extension mechanisms, before providing a section (Appendix A) that contains a template to be the starting point for any future Internet-Draft about an IODEF extension.
IODEF [RFC5070]の仕様から5年間で、協調的なネットワーク防御の慣行と同様に、脅威環境が進化しました。これらの傾向は、実装と展開を通じて得られた経験とともに、IODEFを拡張する必要性を示しています。このドキュメントでは、これらの拡張機能を定義するためのガイドラインを提供します。最初に、IODEF拡張の適用可能性とIODEF拡張メカニズムを説明する前に、IODEF拡張に関する将来のインターネットドラフトの起点となるテンプレートを含むセクション（付録A）を提供します。
This document is designed to give guidance on the extension of IODEF, especially for those extension authors who may be new to the IETF process. Nothing in this document should be construed as defining policies for the definition of these extensions.
このドキュメントは、特にIETFプロセスに不慣れな拡張機能の作成者向けに、IODEFの拡張機能に関するガイダンスを提供することを目的としています。このドキュメントの内容は、これらの拡張機能の定義に関するポリシーを定義するものとして解釈されるべきではありません。
At publication time, the Managed Incident Lightweight Exchange (MILE) working group of the IETF provides a home for work on IODEF extensions that do not otherwise have a natural home. IODEF extensions that require the expertise of other IETF working groups or other standards development organizations may be done within those groups with consultation of IODEF experts, such as those appointed for review as in [RFC6685].
公開時に、IETFのManaged Incident Lightweight Exchange（MILE）ワーキンググループは、他の方法では本来のホームを持たないIODEF拡張に関する作業のホームを提供します。他のIETFワーキンググループまたは他の標準開発組織の専門知識を必要とするIODEF拡張は、[RFC6685]のようにレビューのために任命された専門家などのIODEF専門家と相談して、それらのグループ内で行うことができます。
Before deciding to extend IODEF, the first step is to determine whether an IODEF extension is a good fit for a given problem. There are two sides to this question:
IODEFの拡張を決定する前に、最初のステップは、IODEF拡張が特定の問題に適しているかどうかを判断することです。この質問には2つの側面があります。
1. Does the problem involve the reporting or sharing of observations, indications, or other information about an incident, whether in progress or completed, hypothetical or real? "Incident" is defined in the terminology for the original IODEF requirements [RFC3067]: an event that involves a security violation, whether a single attack of a group thereof. If the answer to this question is unequivocally "No", then IODEF is probably not a good choice as a base technology for the application area.
1. 問題には、進行中か、完了したか、仮説的か、現実的かに関わらず、インシデントに関する観察、指摘、またはその他の情報の報告または共有が含まれますか？ 「インシデント」は、元のIODEF要件[RFC3067]の用語で定義されています。これは、セキュリティ違反を含むイベントであり、そのグループの単一の攻撃かどうかにかかわらずです。この質問への答えが明確に「いいえ」である場合、IODEFはおそらくアプリケーション領域のベーステクノロジとしては適切な選択ではありません。
2. Can IODEF adequately represent information about the incident without extension? IODEF has a rich set of incident-relevant classes. If, after detailed examination of the problem area and the IODEF specification, and consultation with IODEF experts, the answer to this question is "Yes", then extension is not necessary.
2. IODEFはインシデントに関する情報を拡張なしで適切に表すことができますか？ IODEFには、インシデントに関連するクラスの豊富なセットがあります。問題領域とIODEF仕様を詳細に調査し、IODEFの専門家に相談した後、この質問に対する回答が「はい」である場合、拡張は必要ありません。
Examples of such extensions to IODEF might include the following:
IODEFに対するそのような拡張の例には、次のものがあります。
o Leveraging existing work in describing aspects of incidents to make IODEF more expressive, by standardized reference to external information bases about incidents and incident-related information
o インシデントおよびインシデント関連情報に関する外部情報ベースへの標準化された参照により、IODEFをより表現力のあるものにするためにインシデントの側面を説明する既存の作業を活用します
o Allowing the description of new types of entities (e.g., related actors) or new types of characteristics of entities (e.g., information related to financial services) involved in an IODEF incident report
o IODEFインシデントレポートに含まれる新しいタイプのエンティティ（関連するアクターなど）またはエンティティの新しいタイプの特性（たとえば、金融サービスに関連する情報）の説明を許可する
o Allowing the representation of new types of indicators, observables, or incidents in an IODEF incident report
o 新しいタイプのインジケーター、オブザーバブル、またはインシデントをIODEFインシデントレポートに表示できるようにする
o Allowing additional semantic or metadata labeling of IODEF Documents (e.g., for handling or disposition instructions, or compliance with data protection and data retention regulations)
o IODEFドキュメントの追加のセマンティックまたはメタデータのラベル付けを許可します（例：処理または廃棄の指示、またはデータ保護とデータ保持規制の遵守のため）
IODEF was designed to be extended through any combination of the following:
IODEFは、以下の任意の組み合わせによって拡張されるように設計されました。
1. extending the enumerated values of Attributes, per Section 5.1 of [RFC5070];
1. [RFC5070]のセクション5.1に従って、属性の列挙値を拡張する。
2. class extension through AdditionalData or RecordItem elements, per Section 5.2 of [RFC5070]; and/or
2. [RFC5070]のセクション5.2に従い、AdditionalDataまたはRecordItem要素によるクラス拡張。および/または
3. containment of the IODEF Document element within an external XML Document, itself containing extension data, as done by Real-time Inter-network Defense (RID) [RFC6545].
3. Real-time Inter-Network Defense（RID）[RFC6545]によって行われる、拡張データを含む外部XMLドキュメント内のIODEF Document要素の包含。
Note that in this final case, the extension will not be directly interoperable with IODEF implementations, and it must "unwrap" the IODEF document from its container; nevertheless, this may be appropriate for certain use cases involving integration of IODEF within external schemas. Extensions using containment of an IODEF Document are not further treated in this document, though the document template in Appendix A may be of some use in defining them.
この最後のケースでは、拡張機能はIODEF実装と直接相互運用できず、そのコンテナーからIODEFドキュメントを「アンラップ」する必要があることに注意してください。それでも、これは、外部スキーマ内でのIODEFの統合を含む特定のユースケースに適している場合があります。 IODEFドキュメントの包含を使用する拡張機能は、このドキュメントではこれ以上扱いませんが、付録Aのドキュメントテンプレートは、それらを定義するのに役立つ場合があります。
Certain attributes containing enumerated values within certain IODEF elements may be extended. For an attribute named "foo", this is achieved by giving the value of "foo" as "ext-value" and adding a new attribute named "ext-foo" containing the extended value. The attributes that can be extended this way are limited to the following, denoted in 'Element@attribute' format, referencing the section in which they are defined in [RFC5070]:
特定のIODEF要素内の列挙値を含む特定の属性は拡張される場合があります。 「foo」という名前の属性の場合、これは「foo」の値を「ext-value」として指定し、拡張値を含む「ext-foo」という名前の新しい属性を追加することによって実現されます。この方法で拡張できる属性は、[Element @ attribute]形式で示され、[RFC5070]で定義されているセクションを参照する以下に制限されます。
Incident@purpose, Section 3.2 AdditionalData@dtype, Section 3.6 Contact@role, Section 3.7 Contact@type, Section 3.7 RegistryHandle@registry, Section 3.7.1 Impact@type, Section 3.10.1 TimeImpact@metric, Section 3.10.2 TimeImpact@duration, Section 3.10.2 HistoryItem@action, Section 3.11.1 Expectation@action, Section 3.13 System@category, Section 3.15 Counter@type, Section 3.16.1 Counter@duration, Section 3.16.1 Address@category, Section 3.16.2 NodeRole@category, Section 3.16.3 RecordPattern@type, Section 3.19.2 RecordPattern@offsetunit, Section 3.19.2 RecordItem@dtype, Section 3.19.3
インシデント@目的、セクション3.2 AdditionalData @ dtype、セクション3.6 Contact @ role、セクション3.7 Contact @ type、セクション3.7 RegistryHandle @ registry、セクション3.7.1 Impact @ type、セクション3.10.1 TimeImpact @ metric、セクション3.10.2 TimeImpact @期間、セクション3.10.2 HistoryItem @ action、セクション3.11.1 Expectation @ action、セクション3.13 System @ category、セクション3.15 Counter @ type、セクション3.16.1 Counter @ duration、セクション3.16.1 Address @ category、セクション3.16.2 NodeRole @ category、セクション3.16.3 RecordPattern @ type、セクション3.19.2 RecordPattern @ offsetunit、セクション3.19.2 RecordItem @ dtype、セクション3.19.3
Note that this list is current as of publication time; the set of IODEF data types may be extended by future specifications that update [RFC5070].
このリストは発行時のものです。一連のIODEFデータ型は、[RFC5070]を更新する将来の仕様によって拡張される可能性があります。
An example definition of an attribute extension is given in Appendix B.
属性拡張の定義の例を付録Bに示します。
IODEF Documents can contain extended scalar or XML data using an AdditionalData element or a RecordItem element. Scalar data extensions must set the "dtype" attribute of the containing element to the data type to reference one of the IODEF data types as enumerated in Section 2 of [RFC5070], and it should use the "meaning" and "formatid" attributes to explain the content of the element.
IODEFドキュメントには、AdditionalData要素またはRecordItem要素を使用して、拡張スカラーまたはXMLデータを含めることができます。スカラーデータ拡張は、[RFC5070]のセクション2で列挙されているように、IODEFデータタイプの1つを参照するために、包含要素の「dtype」属性をデータタイプに設定する必要があり、「意味」および「formatid」属性を使用して要素の内容を説明します。
XML extensions within an AdditionalData or RecordItem element use a dtype of "xml", and they should define a schema for the topmost containing element within the AdditionalData or RecordItem element. An example definition of an element definition is given in Appendix C.
AdditionalDataまたはRecordItem要素内のXML拡張は、「xml」のdtypeを使用し、AdditionalDataまたはRecordItem要素内の最上位に含まれる要素のスキーマを定義する必要があります。要素定義の定義の例を付録Cに示します。
When adding elements to the AdditionalData section of an IODEF document, an extension's namespace and schema should be registered with IANA; see Appendix A.6 for details.
IODEFドキュメントのAdditionalDataセクションに要素を追加する場合、拡張の名前空間とスキーマをIANAに登録する必要があります。詳細については、付録A.6を参照してください。
This document raises no security issues itself. Extensions defined using the template in Appendix A need to provide an analysis of security issues they may raise. See Appendix A.5 for details.
このドキュメント自体にはセキュリティの問題はありません。付録Aのテンプレートを使用して定義された拡張機能は、それらが提起する可能性のあるセキュリティ問題の分析を提供する必要があります。詳細については、付録A.5を参照してください。
Thanks to David Black, Benoit Claise, Martin Duerst, Eran Hammer, Tom Millar, Kathleen Moriarty, Peter Saint-Andre, Robert Sparks, Takeshi Takahashi, Sean Turner, Samuel Weiler, and Peter Yee for their reviews and comments. This work is materially supported by the European Union Seventh Framework Program under grant agreement 257315 (DEMONS).
デビッドブラック、ブノワクレイズ、マーティンデュエルスト、エランハマー、トムミラー、キャスリーンモリアーティ、ピーターサンアンドレ、ロバートスパークス、タカシタカシ、ショーンターナー、サミュエルワイラー、ピーターイーにレビューとコメントをありがとうこの作業は、助成金契約257315（悪魔）に基づく欧州連合第7フレームワークプログラムによって実質的にサポートされています。
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident Object Description Exchange Format", RFC 5070, December 2007.
[RFC5070] Danyliw、R.、Meijer、J。、およびY. Demchenko、「The Incident Object Description Exchange Format」、RFC 5070、2007年12月。
[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月。
[RFC3067] Arvidsson, J., Cormack, A., Demchenko, Y., and J. Meijer, "TERENA'S Incident Object Description and Exchange Format Requirements", RFC 3067, February 2001.
[RFC3067] Arvidsson、J.、Cormack、A.、Demchenko、Y。、およびJ. Meijer、「TERENA'S Incident Object Description and Exchange Format Requirements」、RFC 3067、2001年2月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを作成するためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[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月。
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6545, April 2012.
[RFC6545] Moriarty、K。、「Real-time Inter-network Defense（RID）」、RFC 6545、2012年4月。
[RFC6685] Trammell, B., "Expert Review for Incident Object Description Exchange Format (IODEF) Extensions in IANA XML Registry", RFC 6685, July 2012.
[RFC6685] Trammell、B。、「IANA XMLレジストリのインシデントオブジェクト記述交換フォーマット（IODEF）拡張の専門家レビュー」、RFC 6685、2012年7月。
The document template given in this section is provided as a starting point for writing an Internet-Draft describing an IODEF extension. RFCs are subject to additional formatting requirements and must contain additional sections not described in this template; consult the RFC Editor style guide (http://www.rfc-editor.org/styleguide.html) for more information.
このセクションで提供されるドキュメントテンプレートは、IODEF拡張を記述するInternet-Draftを書くための出発点として提供されます。 RFCには追加のフォーマット要件が適用され、このテンプレートで説明されていない追加のセクションを含める必要があります。詳細については、RFCエディターのスタイルガイド（http://www.rfc-editor.org/styleguide.html）を参照してください。
This template is informational in nature; in case of any future conflict with RFC Editor requirements for Internet-Drafts, those requirements take precedence.
このテンプレートは本質的に情報提供です。今後、インターネットドラフトに関するRFCエディタの要件と矛盾する場合は、それらの要件が優先されます。
The Introduction section lays out the problem being solved by the extension, and motivates the development and deployment of the extension.
「はじめに」セクションでは、拡張機能によって解決される問題を説明し、拡張機能の開発と展開の動機を説明します。
The Terminology section introduces and defines terms specific to the document. Terminology from [RFC5070] or [RFC6545] should be referenced in this section, but not redefined or copied. If [RFC2119] terms are used in the document, this should be noted in the Terminology section.
用語セクションでは、ドキュメントに固有の用語を紹介および定義します。 [RFC5070]または[RFC6545]の用語はこのセクションで参照する必要がありますが、再定義またはコピーしないでください。文書で[RFC2119]用語が使用されている場合、これは用語セクションに記載されている必要があります。
The Applicability section defines the use cases to which the extension is applicable, and it details any requirements analysis done during the development of the extension. The primary goal of this section is to allow readers to see if an extension is indeed intended to solve a given problem. This section should also define and restrict the scope of the extension, as appropriate, by pointing out any non-obvious situations to which it is not intended to apply.
「適用性」セクションでは、拡張機能を適用できるユースケースを定義し、拡張機能の開発中に行われた要件分析について詳しく説明します。このセクションの主な目的は、拡張機能が実際に特定の問題を解決するためのものかどうかを読者が確認できるようにすることです。このセクションでは、必要に応じて、拡張の適用範囲を明確にし、制限する必要があります。
In addition to defining the applicability, this section may also present example situations, which should then be detailed in the examples section, below.
このセクションでは、適用性の定義に加えて、状況の例も示します。この状況については、以下の例のセクションで詳しく説明します。
This section defines the extension.
このセクションでは、拡張機能を定義します。
Extensions to enumerated types are defined in one subsection for each attribute to be extended, enumerating the new values with an explanation of the meaning of each new value. An example enumeration extension is shown in Appendix B, below.
列挙型への拡張は、拡張される属性ごとに1つのサブセクションで定義され、各新しい値の意味の説明とともに新しい値を列挙します。列挙型拡張の例を、以下の付録Bに示します。
Element extensions are defined in one subsection for each element, in top-down order, from the element contained within AdditionalData or RecordItem; an example element extension is shown in Appendix C, below. Each element should be described by a Unified Modeling Language (UML) diagram as in Figure 1, followed by a description of each of the attributes, and a short description of each of the child elements. Child elements should then be defined in a subsequent subsection, if not already defined in the IODEF Document itself, or in another referenced IODEF extension document.
要素の拡張は、AdditionalDataまたはRecordItemに含まれる要素から、各要素の1つのサブセクションで上から下に定義されます。エレメント拡張の例は、以下の付録Cに示されています。各要素は、図1のような統一モデリング言語（UML）の図で記述し、その後に各属性の説明と各子要素の簡単な説明を続けます。次に、子要素は、IODEFドキュメント自体または別の参照されているIODEF拡張ドキュメントでまだ定義されていない場合、後続のサブセクションで定義する必要があります。
+---------------------+
| Element |
+---------------------+
| TYPE attribute0 |<>----------[ChildExactlyOne]
| TYPE attribute1 |<>--{0..1}--[ChildZeroOrOne]
| |<>--{0..*}--[ChildZeroOrMore]
| |<>--{1..*}--[ChildOneOrMore]
+---------------------+
Figure 1: Example UML Element Diagram
図1：UML要素図の例
Elements containing child elements should indicate the multiplicity of those child elements, as shown in the figure above. Allowable TYPEs are enumerated in Section 2 of [RFC5070].
子要素を含む要素は、上の図に示すように、それらの子要素の多重度を示す必要があります。許容されるTYPEは、[RFC5070]のセクション2に列挙されています。
Any security considerations [RFC3552] raised by this extension or its deployment should be detailed in this section. Guidance should focus on ensuring the users of this extension do so in a secure fashion, with special attention to non-obvious implications of the transmission of the information represented by this extension. [RFC3552] may be a useful reference in determining what to cover in this section. This section is required by the RFC Editor.
この拡張機能またはその展開によって提起されたセキュリティ上の考慮事項[RFC3552]については、このセクションで詳しく説明する必要があります。ガイダンスは、この拡張機能のユーザーが安全な方法でそうすることを確実にすることに焦点を当てる必要があります。この拡張機能によって表される情報の送信の明白でない影響に特に注意してください。 [RFC3552]は、このセクションで何をカバーするかを決定する際に役立つ参照になる場合があります。このセクションは、RFCエディターで必要です。
It should also be noted in this section that the security considerations for IODEF [RFC5070] apply to the extension as well.
このセクションでは、IODEF [RFC5070]のセキュリティに関する考慮事項が拡張機能にも適用されることにも注意してください。
Any IANA considerations [RFC5226] for the document should be detailed in this section. Note that IODEF extension documents will generally register new namespaces and schemas. In addition, this section is required by the RFC Editor, so if there are no IANA considerations, the section should exist and contain the text "this document has no actions for IANA".
ドキュメントに関するIANAの考慮事項[RFC5226]は、このセクションで詳しく説明する必要があります。 IODEF拡張ドキュメントは通常、新しい名前空間とスキーマを登録することに注意してください。さらに、このセクションはRFCエディターで必須であるため、IANAに関する考慮事項がない場合は、セクションが存在し、「このドキュメントにはIANAのアクションがありません」というテキストが含まれている必要があります。
IODEF Extensions that represent an enumeration should reference an existing IANA registry or subregistry for the values of that enumeration. If no such registry exists, this section should define a new registry to hold the enumeration's values and define the policies by which additions may be made to the registry.
列挙を表すIODEF拡張は、その列挙の値について既存のIANAレジストリまたはサブレジストリを参照する必要があります。そのようなレジストリが存在しない場合、このセクションでは、列挙の値を保持する新しいレジストリを定義し、レジストリに追加できるポリシーを定義する必要があります。
IODEF Extensions adding elements to the AdditionalData section of an IODEF Document should register their own namespaces and schemas for extensions with IANA; therefore, this section should contain at least a registration request for the namespace and the schema, as follows, modified as appropriate for the extension:
IODEFドキュメントのAdditionalDataセクションに要素を追加するIODEF拡張機能は、拡張用の独自の名前空間とスキーマをIANAに登録する必要があります。したがって、このセクションには、少なくともネームスペースとスキーマの登録リクエストが含まれている必要があります。次のように、拡張機能に合わせて変更されています。
Registration request for the IODEF My-Extension namespace:
IODEF My-Extension名前空間の登録リクエスト：
URI: urn:ietf:params:xml:ns:iodef-myextension-1.0
Registrant Contact: Refer here to the Authors' Addresses section of the document, or to an organizational contact in the case of an extension supported by an external organization.
登録者の連絡先：ドキュメントの「著者のアドレス」セクションを参照するか、外部組織でサポートされている内線番号の場合は組織の連絡先を参照してください。
XML: None
XML：なし
Registration request for the IODEF My-Extension XML schema:
IODEF My-Extension XMLスキーマの登録リクエスト：
URI: urn:ietf:params:xml:schema:iodef-myextension-1.0
Registrant Contact: Refer here to the Authors' Addresses section of the document, or to an organizational contact in the case of an extension supported by an external organization.
登録者の連絡先：ドキュメントの「著者のアドレス」セクションを参照するか、外部組織でサポートされている内線番号の場合は組織の連絡先を参照してください。
XML: Refer here to the XML Schema in Appendix A of the document, or to a well-known external reference in the case of an extension with an externally defined schema.
XML：ドキュメントの付録AのXMLスキーマを参照するか、外部で定義されたスキーマを使用した拡張機能の場合は、よく知られた外部参照を参照してください。
If any of the operational and/or management considerations listed in Appendix A of [RFC5706] apply to the extension, address them in this section. If no such considerations apply, this section can be omitted.
[RFC5706]の付録Aに記載されている運用上または管理上の考慮事項のいずれかが拡張機能に適用される場合は、このセクションで対処してください。そのような考慮事項が当てはまらない場合、このセクションは省略できます。
The XML Schema describing the elements defined in the Extension Definition section is given here. Each of the examples in Appendix A.9 will be verified to validate against this schema by automated tools.
ここでは、拡張定義セクションで定義された要素を記述するXMLスキーマを示します。付録A.9の各例は、自動化ツールによってこのスキーマに対して検証するために検証されます。
This section contains example IODEF Documents illustrating the extension. If example situations are outlined in the Applicability section, documents for those examples should be provided in the same order as in the Applicability section. Example documents will be tested to validate against the schema given in the appendix.
このセクションには、拡張機能を説明するIODEFドキュメントの例が含まれています。 「適用性」セクションで状況の例が概説されている場合、それらの例のドキュメントは「適用性」セクションと同じ順序で提供する必要があります。サンプルドキュメントは、付録に記載されているスキーマに対して検証するためにテストされます。
Appendix B. Example Enumerated Type Extension Definition: Presentation Action
付録B列挙型拡張定義の例：プレゼンテーションアクション
This example extends the IODEF Expectation element to represent the expectation that a slide deck be derived from the IODEF Incident, and that a presentation be given by the recipient's organization thereon.
この例では、IODEF Expectation要素を拡張して、スライドデッキがIODEFインシデントから派生すること、およびプレゼンテーションがその上の受信者の組織によって提供されることの期待を表します。
Attribute: Expectation@action
属性：Expectation @ action
Extended value(s): give-a-presentation
拡張値：プレゼンテーションを行う
Value meaning: generate a slide deck from the provided incident information and give a presentation thereon.
価値の意味：提供されたインシデント情報からスライドデッキを生成し、プレゼンテーションを行います。
Additional considerations: the format of the slide deck is left to the recipient to determine in accordance with its established practices for the presentation of incident reports.
その他の考慮事項：スライドデッキの形式は、インシデントレポートの提示に関する確立された慣行に従って決定するために受信者に委ねられます。
Appendix C. Example Element Definition: Test
付録C.要素定義の例：テスト
This example defines the Test class for labeling IODEF test data.
この例では、IODEFテストデータにラベルを付けるためのTestクラスを定義しています。
The Test class is intended to be included within an AdditionalData element in an IODEF Document. If a Test element is present, it indicates that an IODEF Document contains test data, not a information about a real incident.
Testクラスは、IODEFドキュメントのAdditionalData要素内に含まれることを目的としています。 Test要素が存在する場合、IODEFドキュメントに実際のインシデントに関する情報ではなくテストデータが含まれていることを示します。
The Test class contains information about how the test data was generated.
Testクラスには、テストデータの生成方法に関する情報が含まれています。
+---------------------+
| Test |
+---------------------+
| ENUM category |
| STRING generator |
| |
| |
+---------------------+
Figure 2: The Test Class
図2：テストクラス
The Test class has two attributes:
Testクラスには2つの属性があります。
category: Required. ENUM. The type of test data. The permitted values for this attribute are shown below. The default value is "unspecified".
カテゴリ：必須。 ENUM。テストデータのタイプ。この属性に許可される値を以下に示します。デフォルト値は「未指定」です。
1. unspecified. The document contains test data, but no further information is available.
1. 不特定。ドキュメントにはテストデータが含まれていますが、それ以上の情報はありません。
2. internal. The test data is intended for the internal use of an implementor, and it should not be distributed or used outside the context in which it was generated.
2. 内部。テストデータは実装者の内部使用を目的としており、生成されたコンテキストの外部で配布または使用しないでください。
3. unit. The test data is intended for unit testing of an implementation, and it may be included with the implementation to support this as part of the build and deployment process.
3. 単位。テストデータは、実装の単体テストを目的としており、ビルドおよび展開プロセスの一部としてこれをサポートするために実装に含まれている場合があります。
4. interoperability. The test data is intended for interoperability testing of an implementation, and it may be freely shared to support this purpose.
4. 相互運用性。テストデータは、実装の相互運用性テストを目的としており、この目的をサポートするために自由に共有できます。
generator: Optional. STRING. A free-form string identifying the person, entity, or program that generated the test data.
ジェネレーター：オプション。ストリング。テストデータを生成した人物、エンティティ、またはプログラムを識別する自由形式の文字列。
Author's Address
著者のアドレス
Brian Trammell Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
ブライアントラメルスイス連邦工科大学チューリッヒGloriastrasse 35 8092チューリッヒスイス
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch