draft-ietf-mile-template-05.txt   rfc6684.txt 
mile Working Group B. Trammell Internet Engineering Task Force (IETF) B. Trammell
Internet-Draft ETH Zurich Request for Comments: 6684 ETH Zurich
Intended status: Informational June 8, 2012 Category: Informational July 2012
Expires: December 10, 2012 ISSN: 2070-1721
Guidelines and Template for Defining Extensions to IODEF Guidelines and Template for Defining Extensions to the
draft-ietf-mile-template-05.txt Incident Object Description Exchange Format (IODEF)
Abstract Abstract
This document provides guidelines for extensions to the Incident This document provides guidelines for extensions to the Incident
Object Description Exchange Format (IODEF) [RFC5070] for exchange of Object Description Exchange Format (IODEF) described in RFC 5070 for
incident management data, and contains a template for Internet-Drafts exchange of incident management data, and it contains a template for
describing those extensions, in order to ease the work and improve Internet-Drafts describing those extensions, in order to ease the
the quality of extension descriptions. work and improve the quality of extension descriptions.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on December 10, 2012. 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.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Applicability of Extensions to IODEF . . . . . . . . . . . . . 3 2. Applicability of Extensions to IODEF ............................3
3. Selecting a Mechanism for IODEF Extension . . . . . . . . . . 4 3. Selecting a Mechanism for IODEF Extension .......................3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations .........................................5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgments .................................................5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. References ......................................................5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References .......................................5
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.2. Informative References .....................................5
7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Appendix A. Document Template ......................................7
Appendix A. Document Template . . . . . . . . . . . . . . . . . . 7 A.1. Introduction ................................................7
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7 A.2. Terminology .................................................7
A.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 A.3. Applicability ...............................................7
A.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 A.4. Extension Definition ........................................8
A.4. Extension Definition . . . . . . . . . . . . . . . . . . . 8 A.5. Security Considerations .....................................8
A.5. Security Considerations . . . . . . . . . . . . . . . . . 8 A.6. IANA Considerations .........................................9
A.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 9 A.7. Manageability Considerations ...............................10
A.7. Manageability Considerations . . . . . . . . . . . . . . . 10 A.8. Appendix A: XML Schema Definition for Extension ............10
A.8. Appendix A: XML Schema Definition for Extension . . . . . 10 A.9. Appendix B: Examples .......................................10
A.9. Appendix B: Examples . . . . . . . . . . . . . . . . . . . 10 Appendix B. Example Enumerated Type Extension Definition:
Appendix B. Example Enumerated Type Extension Definition: Presentation Action ...................................10
Presentation Action . . . . . . . . . . . . . . . . . 10 Appendix C. Example Element Definition: Test ......................10
Appendix C. Example Element Definition: Test . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
In the five years since the specification of IODEF [RFC5070], the In the five years since the specification of IODEF [RFC5070], the
threat environment has evolved, as has the practice of cooperative threat environment has evolved, as has the practice of cooperative
network defense. These trends, along with experience gained through network defense. These trends, along with experience gained through
implementation and deployment, have indicated the need to extend implementation and deployment, have indicated the need to extend
IODEF. This document provides guidelines for defining these IODEF. This document provides guidelines for defining these
extensions. It starts by describing the applicability of IODEF extensions. It starts by describing the applicability of IODEF
extensions, and the IODEF extension mechanisms, before providing a extensions, and the IODEF extension mechanisms, before providing a
section (Appendix A) that is itself designed to be copied out and section (Appendix A) that contains a template to be the starting
filled in as the starting point for an Internet-Draft about an IODEF point for any future Internet-Draft about an IODEF extension.
extension.
This document is designed to give guidance on the extension of 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 especially for those extension authors who may be new to the IETF
process. Nothing in this document should be construed as defining process. Nothing in this document should be construed as defining
policies for the definition of these extensions. policies for the definition of these extensions.
At publication time, the Managed Incident Lightweight Exchange (MILE) At publication time, the Managed Incident Lightweight Exchange (MILE)
working group of the IETF provides a home for work on IODEF working group of the IETF provides a home for work on IODEF
extensions that do not otherwise have a natural home. IODEF extensions that do not otherwise have a natural home. IODEF
extensions that require the expertise of other IETF working groups or extensions that require the expertise of other IETF working groups or
other standards development organizations may be done within those other standards development organizations may be done within those
groups with consultation of IODEF experts, such as those appointed groups with consultation of IODEF experts, such as those appointed
for review as in [I-D.ietf-mile-iodef-xmlreg]. for review as in [RFC6685].
2. Applicability of Extensions to IODEF 2. Applicability of Extensions to IODEF
Before deciding to extend IODEF, the first step is to determine Before deciding to extend IODEF, the first step is to determine
whether an IODEF extension is a good fit for a given problem. There whether an IODEF extension is a good fit for a given problem. There
are two sides to this question: are two sides to this question:
1. Does the problem involve the reporting or sharing of 1. Does the problem involve the reporting or sharing of
observations, indications, or other information about an observations, indications, or other information about an
incident, whether in progress or completed, hypothetical or real? incident, whether in progress or completed, hypothetical or real?
skipping to change at page 4, line 6 skipping to change at page 3, line 28
probably not a good choice as a base technology for the probably not a good choice as a base technology for the
application area. application area.
2. Can IODEF adequately represent information about the incident 2. Can IODEF adequately represent information about the incident
without extension? IODEF has a rich set of incident-relevant without extension? IODEF has a rich set of incident-relevant
classes. If, after detailed examination of the problem area and classes. If, after detailed examination of the problem area and
the IODEF specification, and consultation with IODEF experts, the the IODEF specification, and consultation with IODEF experts, the
answer to this question is "Yes", then extension is not answer to this question is "Yes", then extension is not
necessary. necessary.
Examples of such extensions to IODEF might include: Examples of such extensions to IODEF might include the following:
o Leveraging existing work in describing aspects of incidents to o Leveraging existing work in describing aspects of incidents to
make IODEF more expressive, by standardized reference to external make IODEF more expressive, by standardized reference to external
information bases about incidents and incident-related information information bases about incidents and incident-related information
o Allowing the description of new types of entities (e.g., related o Allowing the description of new types of entities (e.g., related
actors) or new types of characteristics of entities (e.g., actors) or new types of characteristics of entities (e.g.,
information related to financial services) involved in an IODEF information related to financial services) involved in an IODEF
incident report incident report
o Allowing the representation of new types of indicators, o Allowing the representation of new types of indicators,
observables, or incidents in an IODEF incident report observables, or incidents in an IODEF incident report
o Allowing additional semantic or metadata labeling of IODEF o Allowing additional semantic or metadata labeling of IODEF
Documents (e.g., for handling or disposition instructions, or Documents (e.g., for handling or disposition instructions, or
compliance with data protection and data retention regulations) compliance with data protection and data retention regulations)
3. Selecting a Mechanism for IODEF Extension 3. Selecting a Mechanism for IODEF Extension
IODEF was designed to be extended through any combination of: IODEF was designed to be extended through any combination of the
following:
1. extending the enumerated values of Attributes, as per section 5.1 1. extending the enumerated values of Attributes, per Section 5.1 of
of [RFC5070]; [RFC5070];
2. class extension through AdditionalData or RecordItem elements, as 2. class extension through AdditionalData or RecordItem elements,
per section 5.2 of [RFC5070]; and/or per Section 5.2 of [RFC5070]; and/or
3. containment of the IODEF-Document element within an external XML 3. containment of the IODEF Document element within an external XML
Document, itself containing extension data, as done by RID Document, itself containing extension data, as done by Real-time
[RFC6545]. Inter-network Defense (RID) [RFC6545].
Note that in this final case, the extension will not be directly Note that in this final case, the extension will not be directly
interoperable with IODEF implementations, and must "unwrap" the IODEF interoperable with IODEF implementations, and it must "unwrap" the
document from its container; nevertheless, this may be appropriate IODEF document from its container; nevertheless, this may be
for certain use cases involving integration of IODEF within external appropriate for certain use cases involving integration of IODEF
schemas. Extensions using containment of an IODEF-Document are not within external schemas. Extensions using containment of an IODEF
further treated in this document, though the document template in Document are not further treated in this document, though the
Appendix A may be of some use in defining them. document template in Appendix A may be of some use in defining them.
Certain attributes containing enumerated values within certain IODEF Certain attributes containing enumerated values within certain IODEF
elements may be extended. For an attribute named "foo", this is elements may be extended. For an attribute named "foo", this is
achieved by giving the value of "foo" as "ext-value", and adding a achieved by giving the value of "foo" as "ext-value" and adding a new
new attribute named "ext-foo" containing the extended value. The attribute named "ext-foo" containing the extended value. The
attributes which can be extended this way are limited to the attributes that can be extended this way are limited to the
following, denoted in 'Element@attribute' format, referencing the following, denoted in 'Element@attribute' format, referencing the
section in which they are defined in [RFC5070]: section in which they are defined in [RFC5070]:
Incident@purpose, section 3.2 Incident@purpose, Section 3.2
AdditionalData@dtype, section 3.6 AdditionalData@dtype, Section 3.6
Contact@role, section 3.7 Contact@role, Section 3.7
Contact@type, section 3.7 Contact@type, Section 3.7
RegistryHandle@registry, section 3.7.1 RegistryHandle@registry, Section 3.7.1
Impact@type, section 3.10.1 Impact@type, Section 3.10.1
TimeImpact@metric, section 3.10.2 TimeImpact@metric, Section 3.10.2
TimeImpact@duration, section 3.10.2 TimeImpact@duration, Section 3.10.2
HistoryItem@action, section 3.11.1 HistoryItem@action, Section 3.11.1
Expectation@action, section 3.13 Expectation@action, Section 3.13
System@category, section 3.15 System@category, Section 3.15
Counter@type, section 3.16.1 Counter@type, Section 3.16.1
Counter@duration, section 3.16.1 Counter@duration, Section 3.16.1
Address@category, section 3.16.2 Address@category, Section 3.16.2
NodeRole@category, section 3.16.3 NodeRole@category, Section 3.16.3
RecordPattern@type, section 3.19.2 RecordPattern@type, Section 3.19.2
RecordPattern@offsetunit, section 3.19.2 RecordPattern@offsetunit, Section 3.19.2
RecordItem@dtype, section 3.19.3 RecordItem@dtype, Section 3.19.3
Note that this list is current as of publication time; the set of Note that this list is current as of publication time; the set of
IODEF Data Types may be extended by future specifications which IODEF data types may be extended by future specifications that update
update [RFC5070]. [RFC5070].
An example definition of an attribute extension is given in An example definition of an attribute extension is given in
Appendix B. Appendix B.
IODEF documents can contain extended scalar or XML data using an IODEF Documents can contain extended scalar or XML data using an
AdditionalData element or a RecordItem element. Scalar data AdditionalData element or a RecordItem element. Scalar data
extensions must set the "dtype" attribute of the containing element extensions must set the "dtype" attribute of the containing element
to the data type to reference one of the IODEF data types as to the data type to reference one of the IODEF data types as
enumerated inin section 2 of [RFC5070], and should use the "meaning" enumerated in Section 2 of [RFC5070], and it should use the "meaning"
and "formatid" attributes to explain the content of the element. and "formatid" attributes to explain the content of the element.
XML extensions within an AdditionalData or RecordItem element use a XML extensions within an AdditionalData or RecordItem element use a
dtype of "xml", and should define a schema for the topmost containing dtype of "xml", and they should define a schema for the topmost
element within the AdditionalData or RecordItem element. An example containing element within the AdditionalData or RecordItem element.
definition of an element definition is given in Appendix C. An example definition of an element definition is given in
Appendix C.
When adding elements to the AdditionalData section of an IODEF When adding elements to the AdditionalData section of an IODEF
document, an extension's namespace and schema should be registered document, an extension's namespace and schema should be registered
with IANA; see Appendix A.6 for details. with IANA; see Appendix A.6 for details.
4. Security Considerations 4. Security Considerations
This document raises no security issues itself. Extensions defined This document raises no security issues itself. Extensions defined
using the template in Appendix A need to provide an analysis of using the template in Appendix A need to provide an analysis of
security issues they may raise. See Appendix A.5 for details. security issues they may raise. See Appendix A.5 for details.
5. IANA Considerations 5. Acknowledgments
This document contains no considerations for IANA.
6. Acknowledgments
Thanks to David Black, Benoit Claise, Martin Duerst, Eran Hammer, Tom Thanks to David Black, Benoit Claise, Martin Duerst, Eran Hammer, Tom
Millar, Kathleen Moriarty, Peter Saint-Andre, Robert Sparks, Takeshi Millar, Kathleen Moriarty, Peter Saint-Andre, Robert Sparks, Takeshi
Takahashi, Sean Turner, Samuel Weiler, and Peter Yee, for their Takahashi, Sean Turner, Samuel Weiler, and Peter Yee for their
reviews and comments. This work is materially supported by the reviews and comments. This work is materially supported by the
European Union Seventh Framework Program under grant agreement 257315 European Union Seventh Framework Program under grant agreement 257315
(DEMONS). (DEMONS).
7. References 6. References
7.1. Normative References 6.1. Normative References
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident
Object Description Exchange Format", RFC 5070, Object Description Exchange Format", RFC 5070,
December 2007. December 2007.
7.2. Informative References 6.2. Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3067] Arvidsson, J., Cormack, A., Demchenko, Y., and J. Meijer, [RFC3067] Arvidsson, J., Cormack, A., Demchenko, Y., and J. Meijer,
"TERENA'S Incident Object Description and Exchange Format "TERENA'S Incident Object Description and Exchange Format
Requirements", RFC 3067, February 2001. Requirements", RFC 3067, February 2001.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
skipping to change at page 7, line 10 skipping to change at page 6, line 20
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and [RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", Management of New Protocols and Protocol Extensions",
RFC 5706, November 2009. RFC 5706, November 2009.
[RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)", [RFC6545] Moriarty, K., "Real-time Inter-network Defense (RID)",
RFC 6545, April 2012. RFC 6545, April 2012.
[I-D.ietf-mile-iodef-xmlreg] [RFC6685] Trammell, B., "Expert Review for Incident Object
Trammell, B., "Expert Review for IODEF Extensions in IANA Description Exchange Format (IODEF) Extensions in IANA XML
XML Registry", draft-ietf-mile-iodef-xmlreg-01 (work in Registry", RFC 6685, July 2012.
progress), May 2012.
Appendix A. Document Template Appendix A. Document Template
The document template given in this section is provided as a starting The document template given in this section is provided as a starting
point for writing an Internet-Draft describing an IODEF extension. point for writing an Internet-Draft describing an IODEF extension.
RFCs are subject to additional formatting requirements and must RFCs are subject to additional formatting requirements and must
contain additional sections not described in this template; consult contain additional sections not described in this template; consult
the RFC Editor style guide the RFC Editor style guide
(http://www.rfc-editor.org/styleguide.html) for more information. (http://www.rfc-editor.org/styleguide.html) for more information.
This template is informational in nature; in case of any future This template is informational in nature; in case of any future
conflict with RFC Editor requirements for Internet-Drafts, those conflict with RFC Editor requirements for Internet-Drafts, those
requirements take precedence. requirements take precedence.
A.1. Introduction A.1. Introduction
The introduction section introduces the problem being solved by the The Introduction section lays out the problem being solved by the
extension, and motivates the development and deployment of the extension, and motivates the development and deployment of the
extension. extension.
A.2. Terminology A.2. Terminology
The terminology section introduces and defines terms specific to the The Terminology section introduces and defines terms specific to the
document. Terminology from [RFC5070] or [RFC6545] should be document. Terminology from [RFC5070] or [RFC6545] should be
referenced in this section, but not redefined or copied. If referenced in this section, but not redefined or copied. If
[RFC2119] terms are used in the document, this should be noted in the [RFC2119] terms are used in the document, this should be noted in the
terminology section. Terminology section.
A.3. Applicability A.3. Applicability
The applicability section defines the use cases to which the The Applicability section defines the use cases to which the
extension is applicable, and details any requirements analysis done extension is applicable, and it details any requirements analysis
during the development of the extension. The primary goal of this done during the development of the extension. The primary goal of
section is to allow readers to see if an extension is indeed intended this section is to allow readers to see if an extension is indeed
to solve a given problem. This section should also define and intended to solve a given problem. This section should also define
restrict the scope of the extension, as appropriate, by pointing out and restrict the scope of the extension, as appropriate, by pointing
any non-obvious situations to which it is not intended to apply. out any non-obvious situations to which it is not intended to apply.
In addition to defining the applicability, this section may also In addition to defining the applicability, this section may also
present example situations, which should then be detailed in the present example situations, which should then be detailed in the
examples section, below. examples section, below.
A.4. Extension Definition A.4. Extension Definition
This section defines the extension. This section defines the extension.
Extensions to enumerated types are defined in one subsection for each Extensions to enumerated types are defined in one subsection for each
attribute to be extended, enumerating the new values with an attribute to be extended, enumerating the new values with an
explanation of the meaning of each new value. An example enumeration explanation of the meaning of each new value. An example enumeration
extension is shown in Appendix B, below. extension is shown in Appendix B, below.
Element extensions are defined in one subsection for each element, in Element extensions are defined in one subsection for each element, in
top-down order, from the element contained within AdditionalData or top-down order, from the element contained within AdditionalData or
RecordItem; an example element extension is shown in Appendix C, RecordItem; an example element extension is shown in Appendix C,
below. Each element should be described by a UML diagram as in below. Each element should be described by a Unified Modeling
Figure 1, followed by a description of each of the attributes, and a Language (UML) diagram as in Figure 1, followed by a description of
short description of each of the child elements. Child elements each of the attributes, and a short description of each of the child
should then be defined in a subsequent subsection, if not already elements. Child elements should then be defined in a subsequent
defined in the IODEF document itself, or in another referenced IODEF subsection, if not already defined in the IODEF Document itself, or
extension document. in another referenced IODEF extension document.
+---------------------+ +---------------------+
| Element | | Element |
+---------------------+ +---------------------+
| TYPE attribute0 |<>----------[ChildExactlyOne] | TYPE attribute0 |<>----------[ChildExactlyOne]
| TYPE attribute1 |<>--{0..1}--[ChildZeroOrOne] | TYPE attribute1 |<>--{0..1}--[ChildZeroOrOne]
| |<>--{0..*}--[ChildZeroOrMore] | |<>--{0..*}--[ChildZeroOrMore]
| |<>--{1..*}--[ChildOneOrMore] | |<>--{1..*}--[ChildOneOrMore]
+---------------------+ +---------------------+
Figure 1: Example UML Element Diagram Figure 1: Example UML Element Diagram
Elements containing child elements should indicate the multiplicity Elements containing child elements should indicate the multiplicity
of those child elements, as shown in the figure above. Allowable of those child elements, as shown in the figure above. Allowable
TYPEs are are enumerated in section 2 of [RFC5070]. TYPEs are enumerated in Section 2 of [RFC5070].
A.5. Security Considerations A.5. Security Considerations
[SECDIR and RFC-EDITOR NOTE: Despite the title, this section is NOT a
Security Considerations section, rather a template Security
Considerations section for future extension documents to be built
from this template. See Section 4 for Security Considerations for
this document.]
Any security considerations [RFC3552] raised by this extension or its Any security considerations [RFC3552] raised by this extension or its
deployment should be detailed in this section. Guidance should focus deployment should be detailed in this section. Guidance should focus
on ensuring the users of this extension do so in a secure fashion, on ensuring the users of this extension do so in a secure fashion,
with special attention to non-obvious implications of the with special attention to non-obvious implications of the
transmission of the information represented by this extension. transmission of the information represented by this extension.
[RFC3552] may be a useful reference in determining what to cover in [RFC3552] may be a useful reference in determining what to cover in
this section. This section is required by the RFC Editor. this section. This section is required by the RFC Editor.
It should also be noted in this section that the security It should also be noted in this section that the security
considerations for IODEF [RFC5070] apply to the extension as well. considerations for IODEF [RFC5070] apply to the extension as well.
A.6. IANA Considerations A.6. IANA Considerations
[IANA and RFC-EDITOR NOTE: Despite the title, this section is NOT an
IANA Considerations section, rather a template IANA Considerations
section for future extension documents to be built from this
template. See Section 5 for IANA Considerations for this document.]
Any IANA considerations [RFC5226] for the document should be detailed Any IANA considerations [RFC5226] for the document should be detailed
in this section. Note that IODEF extension documents will generally in this section. Note that IODEF extension documents will generally
register new namespaces and schemas. In addition, this section is register new namespaces and schemas. In addition, this section is
required by the RFC Editor, so if there are no IANA considerations, required by the RFC Editor, so if there are no IANA considerations,
the section should exist and contain the text "this document has no the section should exist and contain the text "this document has no
actions for IANA". actions for IANA".
IODEF Extensions which represent an enumeration should reference an IODEF Extensions that represent an enumeration should reference an
existing IANA registry or subregistry for the values of that existing IANA registry or subregistry for the values of that
enumeration. If no such registry exists, this section should define enumeration. If no such registry exists, this section should define
a new registry to hold the enumeration's values, and define the a new registry to hold the enumeration's values and define the
policies by which additions may be made to the registry. policies by which additions may be made to the registry.
IODEF Extensions adding elements to the AdditionalData section of an IODEF Extensions adding elements to the AdditionalData section of an
IODEF document should register their own namespaces and schemas for IODEF Document should register their own namespaces and schemas for
extensions with IANA; therefore, this section should contain at least extensions with IANA; therefore, this section should contain at least
a registration request for the namespace and the schema, as follows, a registration request for the namespace and the schema, as follows,
modified as appropriate for the extension: modified as appropriate for the extension:
Registration request for the IODEF My-Extension namespace: Registration request for the IODEF My-Extension namespace:
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 Registrant Contact: Refer here to the Authors' Addresses section of
the document, or to an organizational contact in the case of an the document, or to an organizational contact in the case of an
extension supported by an external organization. extension supported by an external organization.
XML: None XML: None
Registration request for the IODEF My-Extension XML schema: Registration request for the IODEF My-Extension XML schema:
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
Registrant Contact: Refer here to the Authors' Addresses section of
the document, or to an organizational contact in the case of an the document, or to an organizational contact in the case of an
extension supported by an external organization. extension supported by an external organization.
XML: Refer here to the XML Schema in Appendix A of the document, or 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 to a well-known external reference in the case of an extension with
an externally-defined schema. an externally defined schema.
A.7. Manageability Considerations A.7. Manageability Considerations
If any of the operational and/or management considerations listed in If any of the operational and/or management considerations listed in
Appendix A of [RFC5706] apply to the extension, address them in this Appendix A of [RFC5706] apply to the extension, address them in this
section. If no such considerations apply, this section can be section. If no such considerations apply, this section can be
omitted. omitted.
A.8. Appendix A: XML Schema Definition for Extension A.8. Appendix A: XML Schema Definition for Extension
The XML Schema describing the elements defined in the Extension The XML Schema describing the elements defined in the Extension
Defintion section is given here. Each of the examples in Definition section is given here. Each of the examples in
Appendix A.9 will be verified to validate against this schema by Appendix A.9 will be verified to validate against this schema by
automated tools. automated tools.
A.9. Appendix B: Examples A.9. Appendix B: Examples
This section contains example IODEF-Documents illustrating the This section contains example IODEF Documents illustrating the
extension. If example situations are outlined in the applicability extension. If example situations are outlined in the Applicability
section, documents for those examples should be provided in the same section, documents for those examples should be provided in the same
order as in the applicability section. Example documents will be order as in the Applicability section. Example documents will be
tested to validate against the schema given in the appendix. tested to validate against the schema given in the appendix.
Appendix B. Example Enumerated Type Extension Definition: Presentation Appendix B. Example Enumerated Type Extension Definition: Presentation
Action Action
This example extends the IODEF Expectation element to represent the This example extends the IODEF Expectation element to represent the
expectation that a slide deck be derived from the IODEF Incident, and expectation that a slide deck be derived from the IODEF Incident, and
that a presentation be given by the recipient's organization thereon. that a presentation be given by the recipient's organization thereon.
Attribute: Expectation@action Attribute: Expectation@action
skipping to change at page 11, line 17 skipping to change at page 11, line 8
This example defines the Test class for labeling IODEF test data. This example defines the Test class for labeling IODEF test data.
The Test class is intended to be included within an AdditionalData The Test class is intended to be included within an AdditionalData
element in an IODEF Document. If a Test element is present, it element in an IODEF Document. If a Test element is present, it
indicates that an IODEF Document contains test data, not a indicates that an IODEF Document contains test data, not a
information about a real incident. information about a real incident.
The Test class contains information about how the test data was The Test class contains information about how the test data was
generated. generated.
+---------------------+ +---------------------+
| Test | | Test |
+---------------------+ +---------------------+
| ENUM category | | ENUM category |
| STRING generator | | STRING generator |
| | | |
| | | |
+---------------------+ +---------------------+
Figure 2: The Test class Figure 2: The Test Class
The Test class has two attributes: The Test class has two attributes:
category: Required. ENUM. The type of test data. The permitted category: Required. ENUM. The type of test data. The permitted
values for this attribute are shown below. The default value is values for this attribute are shown below. The default value is
"unspecified". "unspecified".
1. unspecified. The document contains test data, but no further 1. unspecified. The document contains test data, but no further
information is available. information is available.
2. internal. The test data is intended for the internal use of 2. internal. The test data is intended for the internal use of
an implementor, and should not be distributed or used outside an implementor, and it should not be distributed or used
the context in which it was generated. outside the context in which it was generated.
3. unit. The test data is intended for unit testing of an 3. unit. The test data is intended for unit testing of an
implementation, and may be included with the implementation to implementation, and it may be included with the implementation
support this as part of the build and deployment process. to support this as part of the build and deployment process.
4. interoperability. The test data is intended for 4. interoperability. The test data is intended for
interoperability testing of an implementation, and may be interoperability testing of an implementation, and it may be
freely shared to support this purpose. freely shared to support this purpose.
generator: Optional. STRING. A free-form string identifying the generator: Optional. STRING. A free-form string identifying the
person, entity, or program which generated the test data. person, entity, or program that generated the test data.
Author's Address Author's Address
Brian Trammell Brian Trammell
Swiss Federal Institute of Technology Zurich Swiss Federal Institute of Technology Zurich
Gloriastrasse 35 Gloriastrasse 35
8092 Zurich 8092 Zurich
Switzerland Switzerland
Phone: +41 44 632 70 13 Phone: +41 44 632 70 13
Email: trammell@tik.ee.ethz.ch EMail: trammell@tik.ee.ethz.ch
 End of changes. 52 change blocks. 
159 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/