draft-ietf-mile-template-00.txt   draft-ietf-mile-template-01.txt 
MILE B. Trammell mile Working Group B. Trammell
Internet-Draft ETH Zurich Internet-Draft ETH Zurich
Intended status: BCP November 17, 2011 Intended status: BCP February 16, 2012
Expires: May 20, 2012 Expires: August 19, 2012
Guidelines for Extensions to IODEF for Managed Incident Lightweight Guidelines for Extensions to IODEF for Managed Incident Lightweight
Exchange Exchange
draft-ietf-mile-template-00.txt draft-ietf-mile-template-01.txt
Abstract Abstract
This document provides guidelines for extensions to IODEF [RFC5070] This document provides guidelines for extensions to IODEF [RFC5070]
for lightweight exchange of incident management data, and contains a for exchange of incident management data, and contains a template for
template for Internet-Drafts describing those extensions, in order to Internet-Drafts describing those extensions, in order to ease the
ease the work and improve the quality of extension descriptions. It work and improve the quality of extension descriptions. It also
also specifies additional Expert Review of XML Schemas used to specifies additional Expert Review of XML Schemas used to describe
describe these extensions. these extensions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 20, 2012. This Internet-Draft will expire on August 19, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . 8
A.4. Extension Definition . . . . . . . . . . . . . . . . . . . 8 A.4. Extension Definition . . . . . . . . . . . . . . . . . . . 8
A.4.1. IODEF Data Types . . . . . . . . . . . . . . . . . . . 8 A.4.1. IODEF Data Types . . . . . . . . . . . . . . . . . . . 9
A.4.2. Example Enumerated Type Extension Definition: A.5. Security Considerations . . . . . . . . . . . . . . . . . 10
E.164 Address . . . . . . . . . . . . . . . . . . . . 9 A.6. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
A.4.3. Example Element Definition: Test . . . . . . . . . . . 10 A.7. Appendix A: XML Schema Definition for Extension . . . . . 11
A.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 11 A.8. Appendix B: Examples . . . . . . . . . . . . . . . . . . . 11
A.6. Security Considerations . . . . . . . . . . . . . . . . . 11 Appendix B. Example Enumerated Type Extension Definition:
A.7. IANA Considerations . . . . . . . . . . . . . . . . . . . 11 E.164 Address . . . . . . . . . . . . . . . . . . . . 11
A.8. Appendix: XML Schema Definition for Extension . . . . . . 12 Appendix C. Example Element Definition: Test . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Since the specification of IODEF [RFC5070], the evolution of the In the five years since the specification of IODEF [RFC5070], the
threat environment and the practice of cooperative network defense, threat environment has evolved, as has the practice of cooperative
along with continued implementation and deployment, has indicated the network defense. These trends, along with experience gained through
need for guidelines for the implementation and extension of IODEF. implementation and deployment, have indicated the need to extend
This document provides these guidelines. It starts by describing the IODEF. This document provides guidelines for defining these
applicability of IODEF extensions, and the IODEF extension extensions. It starts by describing the applicability of IODEF
mechanisms, before providing a section Appendix A that is itself extensions, and the IODEF extension mechanisms, before providing a
designed to be copied out and filled in as the starting point of an section Appendix A that is itself designed to be copied out and
Internet-Draft about an IODEF extension. filled in as the starting point of an Internet-Draft about an IODEF
extension.
Additionally, IODEF extensions via class extension through Additionally, IODEF extensions through AdditionalData and RecordItem
AdditionalData and RecordItem elements, as per section 5.2 of elements, as per section 5.2 of [RFC5070], generally register their
[RFC5070], generally register their namespaces and schemas with the namespaces and schemas with the IANA XML Namespace registry at
IANA XML Namespace registry at
http://www.iana.org/assignments/xml-registry/ns.html and the IANA XML http://www.iana.org/assignments/xml-registry/ns.html and the IANA XML
Schema registry at Schema registry at
http://www.iana.org/assignments/xml-registry/schema.html, http://www.iana.org/assignments/xml-registry/schema.html,
respectively [RFC3688]. In addition to schema reviews required by respectively [RFC3688]. In addition to schema reviews required by
IANA, these registry requests should be accompanied by a review by IANA, these registry requests should be accompanied by a review by
IODEF experts to ensure the specified AdditionalData and/or IODEF experts to ensure the specified AdditionalData and/or
RecordItem contents are compatible with IODEF and with other existing RecordItem contents are compatible with IODEF and with other existing
IODEF extensions. This document specifies that review in Section 5. IODEF extensions. This document specifies that review in Section 5.
2. Applicability of Extensions to IODEF 2. Applicability of Extensions to IODEF
skipping to change at page 4, line 5 skipping to change at page 4, line 5
technology for the application area. technology for the 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 reasonably rich set of incident- without extension? IODEF has a reasonably rich set of incident-
relevant classes. If, after examination of the problem area and relevant classes. If, after examination of the problem area and
the IODEF specification, the answer to this question is "Yes", the IODEF specification, the answer to this question is "Yes",
then extension is not necessary. then extension is not necessary.
A non-exhaustive list of good candidate extensions to IODEF includes: A non-exhaustive list of good candidate extensions to IODEF includes:
1. Allowing standardized reference to external information bases o Leveraging existing work in describing aspects of incidents to
about incidents and incident-relevant information: leveraging make IODEF more expressive, by standardized reference to external
existing work in describing aspects of incidents to make IODEF information bases about incidents and incident-related information
more expressive
2. 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.,
financial services-related information) involved in an IODEF information related to financial services) involved in an IODEF
incident report incident report
3. 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:
1. extending the enumerated values of Attributes, as per section 5.1 1. extending the enumerated values of Attributes, as per section 5.1
of [RFC5070]; of [RFC5070];
2. class extension through AdditionalData and RecordItem elements, 2. class extension through AdditionalData and RecordItem elements,
as per section 5.2 of [RFC5070]; and/or as per section 5.2 of [RFC5070]; and/or
skipping to change at page 4, line 44 skipping to change at page 4, line 43
document from its container; nevertheless, this may be appropriate document from its container; nevertheless, this may be appropriate
for certain use cases involving integration with IODEF within for certain use cases involving integration with IODEF within
external schemas. Extensions using containment of an IODEF-Document external schemas. Extensions using containment of an IODEF-Document
are not further treated in this document, though the document are not further treated in this document, though the document
template in Appendix A may be of some use in defining them. 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 attribute named "ext-foo" containing the extended value. The new attribute named "ext-foo" containing the extended value. The
attributes which can be extended in this way are defined in attributes which can be extended in this way are defined in Section
[RFC5070], and limited to the following: 5.1 of [RFC5070], and limited to the following:
o Incident@purpose o Incident@purpose
o Contact@role o Contact@role
o Contact@type
o Contact@type
o RegistryHandle@registry o RegistryHandle@registry
o Impact@type o Impact@type
o TimeImpact@metric o TimeImpact@metric
o TimeImpact@duration o TimeImpact@duration
o HistoryItem@action o HistoryItem@action
skipping to change at page 5, line 37 skipping to change at page 5, line 35
o RecordPattern@type o RecordPattern@type
o RecordPattern@offsetunit o RecordPattern@offsetunit
o AdditionalData@dtype o AdditionalData@dtype
o RecordItem@dtype o RecordItem@dtype
An example definition of an attribute extension is given in An example definition of an attribute extension is given in
Appendix A.4.2. 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 in Appendix A.4.1, and SHOULD define the use the "meaning" enumerated in Appendix A.4.1, and SHOULD define the 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 root element dtype of "xml", and SHOULD define a schema for the root element
within the AdditionalData or RecordItem attribute. An example within the AdditionalData or RecordItem attribute. An example
definition of an element definition is given in Appendix A.4.3. definition of an element definition is given in Appendix C.
4. Security Considerations 4. Security Considerations
This document defines a template for MILE extensions to the IODEF and This document defines a template for extensions to IODEF; the
RID documents; as such, it has no security considerations on its own. security considerations for IODEF [RFC5070] apply.
5. IANA Considerations 5. IANA Considerations
Changes to the XML Schema registry for schema names beginning with Changes to the XML Schema registry for schema names beginning with
"urn:ietf:params:xml:schema:iodef" are subject to an additional IODEF "urn:ietf:params:xml:schema:iodef" are subject to an additional IODEF
Expert Review [RFC5226]. The IODEF expert(s) for these reviews will Expert Review [RFC5226]. The IODEF expert(s) for these reviews will
be designated by the IETF Security Area Directors. be designated by the IETF Security Area Directors.
[IANA NOTE: The authors request that IANA include a note at the top [IANA NOTE: The authors request that IANA include a note at the top
of http://www.iana.org/assignments/xml-registry/schema.html, stating of http://www.iana.org/assignments/xml-registry/schema.html, stating
"Changes to the XML Schema registry for schema names beginning with "Changes to the XML Schema registry for schema names beginning with
'urn:ietf:params:xml:schema:iodef' are subject to an additional IODEF 'urn:ietf:params:xml:schema:iodef' are subject to an additional IODEF
Expert Review [RFC5226]," and naming the designated expert.] Expert Review [RFC5226]," and naming the designated expert.]
6. References 6. Acknowledgments
6.1. Normative References Thanks to David Black, Takeshi Takahashi, Tom Millar, and Kathleen
Moriarty for their comments. This work is materially supported by
the European Union Seventh Framework Program under grant agreement
257315 (DEMONS).
7. References
7.1. Normative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)", [RFC6045] Moriarty, K., "Real-time Inter-network Defense (RID)",
RFC 6045, November 2010. RFC 6045, November 2010.
6.2. Informative References 7.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.
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998. Architecture", RFC 2373, July 1998.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
skipping to change at page 8, line 18 skipping to change at page 8, line 29
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 the new value. An example enumeration explanation of the meaning of the new value. An example enumeration
extension is shown in Appendix A.4.2, 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 A.4.3, 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 UML diagram as in
Figure 1, followed by a description of each of the attributes, and a Figure 1, followed by a description of each of the attributes, and a
short description of each of the child elements. Child elements short description of each of the child elements. Child elements
should then be defined in a subsequent subsection, if not already should then be defined in a subsequent subsection, if not already
defined in the IODEF document itself, or in another referenced MILE defined in the IODEF document itself, or in another referenced MILE
extension document. extension document.
+---------------------+ +---------------------+
| Element | | Element |
+---------------------+ +---------------------+
skipping to change at page 9, line 48 skipping to change at page 10, line 10
o URL for URLs as in [RFC2396]. o URL for URLs as in [RFC2396].
In addition to these simple data types, IODEF provides a compound In addition to these simple data types, IODEF provides a compound
data type for representing network address information. Addresses data type for representing network address information. Addresses
included within an extension element should be represented by included within an extension element should be represented by
containing an IODEF:Address element, which supports IPv4 and containing an IODEF:Address element, which supports IPv4 and
[RFC2373] IPv6 addresses, as well as MAC, ATM, and BGP autonomous [RFC2373] IPv6 addresses, as well as MAC, ATM, and BGP autonomous
system numbers. Application-layer addresses should be represented system numbers. Application-layer addresses should be represented
with the URL simple attribute type, instead. with the URL simple attribute type, instead.
A.4.2. Example Enumerated Type Extension Definition: E.164 Address 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
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 an extension.
It should also be noted in this section that the security
considerations for IODEF [RFC5070] apply to the extension as well.
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
in this section; if none, the section should exist and contain the
text "this document has no actions for IANA".
IODEF Extensions which 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 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:
Registration request for the IODEF My-Extension namespace:
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
Registration request for the IODEF My-Extension XML schema:
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 the appendix of the document,
or to a well-known external reference in the case of an extension
with an externally-defined schema.
A.7. Appendix A: XML Schema Definition for Extension
The XML Schema describing the elements defined in the Extension
Defintion section is given here. Each of the examples in section
Appendix A.8 should be verified to validate against this schema by
automated tools.
A.8. Appendix B: Examples
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 should be
tested to validate against the schema given in the appendix.
Appendix B. Example Enumerated Type Extension Definition: E.164 Address
This example extends the IODEF Address element to support the This example extends the IODEF Address element to support the
encoding of ENUM-mapped telephone numbers [RFC6116]. encoding of ENUM-mapped telephone numbers [RFC6116].
Attribute: Address@category Attribute: Address@category
Extended value(s): enum-e164 Extended value(s): enum-e164
Content format: An E.164 telephone number encoded as a domain name in Value meaning and format: An E.164 telephone number encoded as a
the e164.int space, e.g. "2.1.2.1.5.5.5.2.1.2.1.e164.int." for +1 212 domain name in the e164.int space, e.g.
555 1212, as per section 3.2 of [RFC6116]. "2.1.2.1.5.5.5.2.1.2.1.e164.int." for +1 212 555 1212, as per section
3.2 of [RFC6116].
Additional considerations: none. Additional considerations: none.
A.4.3. Example Element Definition: Test Appendix C. Example Element Definition: Test
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 reference indicates that an IODEF Document contains test data, not a reference
to a real incident. to 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.
skipping to change at page 11, line 13 skipping to change at page 13, line 8
implementation, and may be included with the implementation to implementation, and may be included with the implementation to
support this as part of the build and deployment process. 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 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 which generated the test data.
A.5. Examples
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 should be
tested to validate against the schema given in the appendix.
A.6. 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
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 or storage of the information represented by an
extension.
A.7. 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
in this section; if none, the section should exist and contain the
text "this document has no actions for 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:
Registration request for the IODEF My-Extension namespace:
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
Registration request for the IODEF My-Extension XML schema:
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 the appendix of the document,
or to a well-known external reference in the case of an extension
with an externally-defined schema.
A.8. Appendix: XML Schema Definition for Extension
The XML Schema describing the elements defined in the Extension
Defintion section is given here. Each of the examples in section
Appendix A.5 should be verified to validate against this schema by
automated tools.
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. 29 change blocks. 
134 lines changed or deleted 150 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/