One document matched: draft-trammell-mile-template-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="info" docName="draft-trammell-mile-template-00.txt">
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>

<front>
  <title abbrev="MILE Template">
    Guidelines for Extensions to IODEF for Managed Incident Lightweight Exchange
  </title>
  <author initials="B." surname="Trammell" fullname="Brian Trammell">
    <organization abbrev="ETH Zurich">
      Swiss Federal Institute of Technology Zurich 
    </organization>
    <address>
      <postal>
        <street>Gloriastrasse 35</street>
        <city>8092 Zurich</city>
        <country>Switzerland</country>
      </postal>
      <phone>+41 44 632 70 13</phone>
      <email>trammell@tik.ee.ethz.ch</email>
    </address>
  </author>
  <date month='July' day='4' year='2011' />
  <area>Security</area>
  <workgroup>Individual Submission</workgroup>
  <abstract> 

    <t>This document provides guidelines for extensions to <xref target="RFC5070">IODEF</xref> for lightweight exchange of incident management data, and contains a template for Internet-Drafts describing those extensions, in order to ease the work and improve the quality of extension descriptions.</t>

  </abstract>
</front>

<middle>

<section title="Introduction" anchor="sec-intro">
  <t>[TODO]</t>
</section>

<section title="Applicability of Extensions to IODEF">
  
  <t>[TODO: explain what makes a good IODEF extension. basically: is it a noun?]</t>

</section>

<section title="Selecting a Mechanism for IODEF Extension" anchor="sec-mechanisms">

  <t>IODEF was designed to be extended through any combination of</t>

    <list style="numbers">
      <t>extending the enumerated values of Attributes, as per section 5.1 of <xref target="RFC5070"/>;</t>
      <t>class extension through AdditionalData and RecordItem elements, as per section 5.2 of <xref target="RFC5070"/>; and/or</t>
      <t>containment of the IODEF-Document element within an external XML Document, itself containing extension data.</t>
    </list>

    <t>Note that in this final case, the extension will not be directly
    interoperable with IODEF implementations, and must "unwrap" the IODEF
    document from its container; nevertheless, this may be appropriate for
    certain use cases involving integration with IODEF within external
    schemas.</t>

</section>

<section title="Conventions used in MILE Extension Documents" anchor="sec-conventions">

  <t>This section outlines conventions used in MILE extension documents. Following these conventions ensures the documents produced by the MILE effort have a consistent terminology and are easily readable as a set.</t>

  
</section>

<section title="Document Template" anchor="sec-template">
  
  <t>Documents describing am IODEF extension should follow the document template given in this section.</t>

  <section title="Introduction" anchor="ext-intro">

    <t>The introduction section introduces the problem being solved by the
    extension, and motivates the development and deployment of the
    extension.</t>

  </section>

  <section title="Terminology" anchor="ext-terminology">

    <t>The terminology section introduces and defines terms specific to the
    document. Terminology from <xref target="RFC5070"/> or <xref
    target="RFC6045"/> should be referenced in this section, but not redefined
    or copied. If <xref target="RFC2119"/> terms are used in the document,
    this should be noted in the terminology section.</t>

  </section>

  <section title="Applicability" anchor="ext-applicability">

    <t>The applicability section defines the use cases to which the extension
    is applicable, and 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 particular
    problem.</t>

    <t>In addition to defining the applicability, this section may also
    present example situations, which should then be detailed in the examples
    section, below.</t>

  </section>

  <section title="Extension Definition" anchor="ext-definition">

    <t>This section defines the extension.</t>
    
     <t>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 the new value. An example enumeration extension is shown
    in <xref target="ext-defenum"/>, below.</t>

    <t>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 <xref
    target="ext-defelem"/>, below. Each element should be described by a UML
    diagram as in <xref target="fig-element"/>, 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 MILE extension document.</t>

<figure title="Example UML Element Diagram"  anchor="fig-element">
  <artwork><![CDATA[
+---------------------+
| Element             |
+---------------------+
| TYPE attribute0     |<>----------[ChildExactlyOne]
| TYPE attribute1     |<>--{0..1}--[ChildZeroOrOne]
|                     |<>--{0..*}--[ChildZeroOrMore]
|                     |<>--{1..*}--[ChildOneOrMore]
+---------------------+
]]></artwork>
</figure>

    <t>Elements containing child elements should indicate the multiplicity of those child elements, as shown in the figure above. Allowable TYPEs are discussed in the following subsection.</t>

	<section title="IODEF Data Types"/>
  
    	<t>The allowable TYPEs for attributes within IODEF are enumerated in section 2 of <xref target="RFC5070"/>, and consist of:</t>
  
	    <list style="symbols">
	      <t>INTEGER</t>
	      <t>REAL</t>
	      <t>CHARACTER</t>
	      <t>STRING</t>
	      <t>ML_STRING (for strings in encodings other than that of the enclosing document)</t>
	      <t>BYTE for bytes or byte vectors in Base 64 encoding</t>
	      <t>HEXBIN for bytes in ascii-hexadecimal encoding</t>
	      <t>ENUM for enumerated types; allowable values of the enumeration must be defined in the attribute definition</t>
	      <t>DATETIME for <xref target="RFC3339">ISO 8601:2000</xref> encoded timestamps</t>
	      <t>TIMEZONE for timezones as encoded in section 2.9 of <xref target="RFC5070"/></t>
	      <t>PORTLIST for port lists as encoded in section 2.10 of <xref target="RFC5070"/></t>
	      <t>POSTAL for postal addresses as defined in section 2.23 of <xref target="RFC4519"/>.</t>
	      <t>NAME for names of natural or legal persons as defined in section 2.3 of <xref target="RFC4519"/>.</t>
	      <t>PHONE for telephone numbers as defined in section 2.35 of <xref target="RFC4519"/>.</t>
	      <t>EMAIL for email addresses as defined in section 3.4.1. of <xref target="RFC2822"/>.</t>
	      <t>URL for URLs as in <xref target="RFC2396"/>.</t>
	    </list>

		<t>In addition to these simple data types, IODEF provides a compound
        data type for representing network address information. Addresses
        included within an extension element should be represented by
        containing an IODEF:Address element, which supports IPv4 and <xref
        target="RFC2373"/> IPv6 addresses, as well as MAC, ATM, and BGP
        autonomous system numbers. Application-layer addresses should be
        represented with the URL simple attribute type, instead.</t>

    <section title="Example Enumerated Type Extension Definition" anchor="ext-defenum">
      <t>[TODO provide an example]</t>
    </section>

    <section title="Example Element Definition" anchor="ext-defelem">
      <t>[TODO provide an example]</t>
    </section>

  </section>

  <section title="Examples" anchor="ext-examples">

    <t>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.</t>

  </section>

  <section title="Security Considerations" anchor="ext-security">

    <t>Any <xref target="RFC3552">security considerations</xref> 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.</t>

  </section>

  <section title="IANA Considerations" anchor="ext-iana">

    <t>[IANA 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 <xref
    target="sec-iana"/> for IANA Considerations for this document.]</t>

    <t>Any <xref target="RFC5226">IANA considerations</xref> 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".</t>

    <t>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:</t>

    <t>Registration request for the IODEF My-Extension namespace:</t>

    <t>  URI: urn:ietf:params:xml:ns:iodef-myextension-1.0 </t>

    <t>  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.</t>

    <t>  XML: None </t>
    
    <t>Registration request for the IODEF My-Extension XML schema:</t>

    <t>  URI: urn:ietf:params:xml:schema:iodef-myextension-1.0 </t>

    <t>  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.</t>

    <t>  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.</t>

  </section>
  
  <section title="Appendix: XML Schema Definition for Extension" anchor="ext-schema">

    <t>The XML Schema describing the elements defined in the Extension Defintion section is given here.</t>

    <t>[TODO: provide guidelines for hacking schemas]</t>

  </section>
  
</section>

<section title="Security Considerations" anchor="sec-security">
  <t>This document defines a template for MILE extensions to the IODEF and RID
  documents; as such, it has no security considerations on its own.</t>
</section>

<section title="IANA Considerations" anchor="sec-iana">
  <t>This document has no actions for IANA.</t>
</section>
</middle>

<back>

<references title="Normative References">
  <?rfc include="reference.RFC.5070" ?>
  <?rfc include="reference.RFC.6045" ?>
</references>

<references title="Informative References">
  <?rfc include="reference.RFC.2119" ?>
  <?rfc include="reference.RFC.2373" ?>
  <?rfc include="reference.RFC.2396" ?>
  <?rfc include="reference.RFC.2822" ?>
  <?rfc include="reference.RFC.3339" ?>
  <?rfc include="reference.RFC.3552" ?>
  <?rfc include="reference.RFC.4519" ?>
  <?rfc include="reference.RFC.5226" ?>
</references>

</back>
</rfc>