Internet Engineering Task Force (IETF) B. Trammell
Request for Comments: 6684 ETH Zurich
Category: Informational July 2012
ISSN: 2070-1721
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.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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/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.
版权所有（c）2012 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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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]规范制定以来的五年中，威胁环境发生了变化，合作网络防御的实践也发生了变化。这些趋势以及通过实施和部署获得的经验表明，需要扩展IODEF。本文档提供了定义这些扩展的指南。它首先描述了IODEF扩展的适用性和IODEF扩展机制，然后提供了一个部分（附录a），该部分包含了一个模板，该模板将作为关于IODEF扩展的任何未来互联网草案的起点。
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.
本文件旨在为IODEF的扩展提供指导，特别是对于那些可能是IETF流程新手的扩展作者。本文档中的任何内容都不应解释为定义这些扩展的策略。
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的托管事件轻型交换（MILE）工作组为IODEF扩展提供了一个工作场所，而IODEF扩展没有一个自然的场所。需要其他IETF工作组或其他标准开发组织专业知识的IODEF扩展可在这些组内完成，并咨询IODEF专家，如[RFC6685]中指定审查的专家。
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扩展是否适合给定问题。这个问题有两个方面：
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节，通过附加数据或记录项元素进行类别扩展；和/或
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. 在外部XML文档中包含IODEF文档元素，其本身包含扩展数据，如实时网络间防御（RID）[RFC6545]所做的那样。
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
Incident@purpose，第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@duration，第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数据。标量数据扩展必须将包含元素的“dtype”属性设置为数据类型，以引用[RFC5070]第2节中列举的一种IODEF数据类型，并且它应该使用“含义”和“格式ID”属性来解释元素的内容。
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”的数据类型，它们应该为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).
感谢David Black、Benoit Claise、Martin Duerst、Eran Hammer、Tom Millar、Kathleen Moriarty、Peter Saint Andre、Robert Sparks、Takeshi Takahashi、Sean Turner、Samuel Weiler和Peter Yee的评论和评论。这项工作得到了欧盟第七框架计划257315（DEMONS）赠款协议的实质性支持。
[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，“事件对象描述交换格式”，RFC 50702007年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事件对象描述和交换格式要求”，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，“在RFCs中编写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]Harrington，D.，“考虑新协议和协议扩展的操作和管理指南”，RFC 5706，2009年11月。
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", RFC 6545, April 2012.
[RFC6545]Moriarty，K.，“实时网络间防御（RID）”，RFC 65452012年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 66852012年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草案的起点。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.
枚举类型的扩展在一个小节中为每个要扩展的属性定义，枚举新值并解释每个新值的含义。下面的附录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中的元素开始，按自上而下的顺序定义；下面的附录C中显示了一个元素扩展示例。每个元素都应该用统一建模语言（UML）图来描述，如图1所示，然后是每个属性的描述，以及每个子元素的简短描述。如果IODEF文档本身或其他引用的IODEF扩展文档中尚未定义子元素，则应在后续小节中定义子元素。
+---------------------+
| Element |
+---------------------+
| TYPE attribute0 |<>----------[ChildExactlyOne]
| TYPE attribute1 |<>--{0..1}--[ChildZeroOrOne]
| |<>--{0..*}--[ChildZeroOrMore]
| |<>--{1..*}--[ChildOneOrMore]
+---------------------+
+---------------------+
| 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].
包含子元素的元素应该指示这些子元素的多重性，如上图所示。[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 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.translate error, please retry
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我的扩展命名空间的注册请求：
URI: urn:ietf:params:xml:ns:iodef-myextension-1.0
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
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期望元素，以表示从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测试数据的测试类。
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.
测试类旨在包含在IODEF文档中的附加数据元素中。如果存在测试元素，则表明IODEF文档包含测试数据，而不是关于真实事件的信息。
The Test class contains information about how the test data was generated.
Test类包含有关如何生成测试数据的信息。
+---------------------+
| Test |
+---------------------+
| ENUM category |
| STRING generator |
| |
| |
+---------------------+
+---------------------+
| Test |
+---------------------+
| ENUM category |
| STRING generator |
| |
| |
+---------------------+
Figure 2: The Test Class
图2：测试类
The Test class has two attributes:
测试类有两个属性：
category: Required. ENUM. The type of test data. The permitted values for this attribute are shown below. The default value is "unspecified".
类别：必选。枚举。测试数据的类型。此属性的允许值如下所示。默认值为“未指定”。
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
Brian Trammell瑞士联邦理工学院苏黎世Gloriastrasse 35 8092瑞士苏黎世
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch