asciidoctor-rfc 0.1.0 → 0.2.0

data/spec/examples/mib-doc-template-xml-06.xml.orig

@@ -0,0 +1,654 @@
+<?txt version="1.0" encoding="US-ASCII"?>
+<!-- change the "txt" on the previous line to "xml" to make this a valid XML2RFC template --> 
+<!-- this is version 5 of this xml2rfc template -->
+<!--
+    DOCTYPE processing
+
+To use this XML template, the rfc2629.dtd from the xml2rfc distribution should 
+be in the local directory. The xml2rfc distribution is available from 
+http://xml.resource.org/
+
+ The ENTITY clauses create an include of the named XML files, which
+contains references written in xml2rfc format.
+
+ XML2RFC offers an include feature described in the XML2RFC README
+  file.  That syntax, however, contradicts the DTD requirements to
+  have <reference> elements within the <references> element, so an 
+  XML parser is likely to find your XML file invalid.  It may be
+  possible that XML2RFC will change their DTD so that the XML file
+  remains valid when their style of include is used.
+
+Some editors, such as XXE, resolve the ENTITY clauses before displaying the 
+document to be edited.
+-->
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
+<!ENTITY rfc2223 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2223.xml">
+<!ENTITY rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
+<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
+<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
+<!ENTITY rfc2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
+<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
+<!ENTITY rfc4181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4181.xml">
+]>
+<?rfc toc="yes"?>
+<?rfc symrefs="yes"?>
+<?rfc compact="yes"?>
+<?rfc subcompact="no"?>
+<?rfc strict="no"?>
+<?rfc rfcedstyle="yes"?>
+<?rfc comments="yes"?>
+<?rfc inline="yes"?>
+
+<!-- Document  section 
+
+Specify the category attribute per RFC2026 
+options are info, std, bcp, or exp. 
+
+docname is the name of the output document. This is optional;
+the default is to use the base portion of the XML filename. 
+
+For Internet-drafts, indicate which intellectual property notice 
+to use per the rules of RFC3978. The value (as of this template) can be:
+    trust200902 -
+    noModificationTrust200902 -
+    noDerivativesTrust200902 -
+    pre5378Trust200902 -
+
+ The Intellectual Property section will be generated automatically by
+  XML2RFC, based on the ipr attribute in the rfc element.
+
+If this document obsoletes an RFC, specify the RFC in the "obsoletes" attribute
+If this document updates an RFC, specify the RFC in the "updates" attribute
+-->
+<rfc category="historic" docName="Your MIB Document name here rev07" ipr="trust200902">
+  <front>
+    <!--
+Enter the full document title and an abbreviated version
+  to use in the page header.
+-->
+
+    <title abbrev="Your MIB Module document name">Your MIB module document name</title>
+
+    <!-- copy the author block as many times as needed, one for each author.-->
+
+    <!-- If the author is acting as editor, use the <role=editor> attribute-->
+
+    <!-- see RFC2223 for guidelines regarding author names -->
+
+    <author fullname="Editor name" initials="Y" role="editor"
+            surname="Name">
+      <organization>Editor affiliation</organization>
+
+      <address>
+        <postal>
+          <street>Editor affiliation address</street>
+
+          <city>Editor affiliation address</city>
+
+          <country>Editor affiliation address</country>
+        </postal>
+
+        <phone>Editor address</phone>
+
+        <email>Editor email</email>
+      </address>
+    </author>
+
+    <!-- month and day will be generated automatically by XML2RFC; 
+be sure the year is current.-->
+
+    <date  year="2008" month="January" day="1" />
+
+    <!-- IETF area is optional -->
+
+    <area>Operations &amp; Management Area</area>
+
+    <!--WG name at the upperleft corner of the doc, 
+IETF is fine for non-WG IETF submissions -->
+
+    <workgroup>Internet Engineering Task Force</workgroup>
+
+    <keyword>Network Management</keyword>
+
+    <keyword>Management Information Base</keyword>
+
+    <keyword>MIB</keyword>
+
+    <keyword>SMIv2</keyword>
+
+    <!--add additional keywords here for IETF website search engine -->
+<abstract>
+
+<t> <cref>This template is for authors of IETF specifications containing MIB
+  modules.  This template can be used as a starting point to produce
+  specifications that comply with the Operations &amp; Management Area
+  guidelines for MIB module internet drafts. Throughout the template, the marker "[TEMPLATE TODO]" is used as a placeholder to indicate an
+  element or text that requires replacement or removal. All the places with [TEMPLATE TODO] markers 
+  should  be replaced or removed before the document is submitted.</cref></t>
+  
+      <t>This memo defines a portion of the Management Information Base (MIB)
+      for use with network management protocols. In particular it defines
+      objects for managing [TEMPLATE TODO].</t>
+      
+
+ <t><cref>[TEMPLATE TODO]: describe what functionality will be managed using this MIB
+ module. It can be good to mention the protocol being managed, and
+ whether there is a particular aspect of the protocol to be managed, or a
+ particular goal of the module. But keep it brief. Remember, don't put any citations 
+ in the abstract, and expand your  acronyms. </cref></t>
+
+ 
+</abstract>
+ 
+    <note title="Foreword to template users">
+      <t>This template is intended to help authors write the surrounding text needed in a
+      MIB module internet draft, but does not provide a template for writing 
+      the MIB module itself.</t>
+
+      <t>Throughout this template, the marker "[TEMPLATE TODO]" is used as a reminder
+      to the template user to indicate an element or text that requires
+      replacement or removal by the template user before submission to the
+      internet draft editor. All [TEMPLATE TODO] markers should be resolved and removed
+      before you submit your document to the internet-draft editor.</t>
+
+      <t>For updated information on MIB module guidelines and templates, see
+      <xref target="RFC4181"></xref> and the OPS Area web page and wiki.</t>
+
+      <t>For information on writing internet drafts or RFCs, see
+      http://www.ietf.org/ietf/1id-guidelines.txt and 
+      RFC2223(bis) <xref target="RFC2223"></xref>, and look
+      at http://www.ietf.org/ID-Checklist.html for issues to note when writing
+      drafts.</t>
+
+      <t>This template is not meant to be a complete list of everything
+      needed to write MIB module internet drafts, but to summarize the often-needed
+      basic features to get a document containing a MIB module started. An
+      important purpose of the template is to aid authors in developing an
+      internet draft that is laid out in a manner consistent with other internet 
+      drafts containing MIB modules. Internet drafts submitted for advancement 
+      to the standards track typically require review by a MIB Doctor. This 
+      template standardizes the layout and naming of sections, includes the 
+      appropriate boilerplate text, and facilitates the development of tools 
+      to automate the checking of MIB module internet drafts, to speed the WG 
+      and IESG review processes.</t>
+
+      <t>An XML2RFC template is also available. For information on XML2RFC, see
+      RFC2629 <xref target="RFC2629"></xref>, and documentation available at
+      http://xml.resource.org. The XML2RFC version includes
+      advice describing how to fill in each section of the template. XML2RFC generates the 
+      actual internet-draft from your information, and automatically handles getting up-to-date 
+      boilerplates, references, and it handles many idnits issues.</t>
+
+      <t>Within the template, there is reference to a SAMPLE-MIB; all references 
+      to SAMPLE-MIB should be removed from your internet draft, and should be 
+      replaced by references to your MIB module, as appropriate.</t>
+      
+      <t>[TEMPLATE TODO] THIS section, the complete section entitled "Note: Foreword to
+      template users" should be removed by the template user from their
+      document before submission.</t>
+
+      <t>[TEMPLATE TODO] Remove all page headings from the template document, and
+      replace them with the appropriate headings for your internet draft.</t>
+    </note>
+   
+<note title="Note to RFC Editor re: [TEMPLATE TODO] markers">   
+ <t>Note to RFC Editor: When a document is developed using this template, the editor of the 
+  document should replace or remove all the places marked [TEMPLATE TODO] before submitting the document.
+  If there are still [TEMPLATE TODO] markers, please send the document back to the editor.</t>
+  </note>
+
+   </front>
+
+  <middle>
+    <section title="Introduction">
+      <!--You can echo the abstract in the Introduction, providing citations here, 
+but you should provide more than just the abstract. -->
+
+      <t>This memo defines a portion of the Management Information Base (MIB)
+      for use with network management protocols. In particular it defines
+      objects for managing the [TEMPLATE TODO].</t>
+
+ <t><cref>[TEMPLATE TODO]: describe what functionality will be managed using this MIB
+ module. Include citations for protocol specifications, architectures, related MIB modules, and protocol-specific
+          management requirements. Provide an overview of why a MIB module is appropriate for this protocol,  whether there is a 
+          particular aspect of the protocol to be managed, and how the module is expected to be used to 
+          achieve particular goals. Highlight anything 'different' about the module. For example, 
+          a read-only MIB module.</cref></t>
+
+    </section>
+
+    <section title="The Internet-Standard Management Framework">
+      <t><cref>The title and text for this section has been copied from the 
+official boilerplate, and should not be modified unless the official boilerplate text 
+from the OPS Area web site has changed. See RFC4818 
+section 3.1 for a discussion of the boilerplate section.</cref></t>
+
+      <t>For a detailed overview of the documents that describe the current
+      Internet-Standard Management Framework, please refer to section 7 of RFC
+      3410 <xref target="RFC3410"></xref>.</t>
+
+      <t>Managed objects are accessed via a virtual information store, termed
+      the Management Information Base or MIB. MIB objects are generally
+      accessed through the Simple Network Management Protocol (SNMP). Objects
+      in the MIB are defined using the mechanisms defined in the Structure of
+      Management Information (SMI). This memo specifies a MIB module that is
+      compliant to the SMIv2, which is described in STD 58, RFC 2578 <xref
+      target="RFC2578"></xref>, STD 58, RFC 2579 <xref
+      target="RFC2579"></xref> and STD 58, RFC 2580 <xref
+      target="RFC2580"></xref>.</t>
+    </section>
+
+    <section title="Conventions">
+      <t><cref>[TEMPLATE TODO] This boilerplate should be used if the RFC2119 key words 
+are used in the internet draft. The text in this section has been 
+copied from the official boilerplate, and should not be modified. </cref></t>
+
+      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+      document are to be interpreted as described in BCP 14, RFC 2119 <xref
+      target="RFC2119"></xref>.</t>
+      
+      </section>
+
+    <!-- ********************************************* -->
+
+    <section title="Overview">
+
+     <t><cref>[TEMPLATE TODO] The narrative part should include an overview section that
+   describes the scope and field of application of the MIB modules
+   defined by the specification.  See RFC4181 section 3.2 for a
+   discussion of the Narrative section.
+</cref></t>
+
+      <t></t>
+
+      </section>
+
+
+    <section title="Structure of the MIB Module">
+
+    <t><cref>[TEMPLATE TODO] The narrative part SHOULD include one or more sections to
+      briefly describe the structure of the MIB modules defined in the
+      specification.</cref></t>
+
+
+      <section title="Textual Conventions">
+
+<t><cref>[TEMPLATE TODO] describe the textual conventions defined in the MIB
+   module, and their purpose. It may be helpful to highlight any textual conventions
+   imported from partner documents. Generic and Common Textual Conventions can be found summarized at 
+the OPS Area web site. If there are no textual conventions used in your MIB module,
+this section should be removed.</cref></t>
+
+        <t></t>
+      </section>
+
+      <section title="The [TEMPLATE TODO] Subtree">
+
+        <t><cref>[TEMPLATE TODO] copy this section for each subtree in the MIB module, and
+        describe the purpose of the subtree. For example, "The fooStats subtree
+        provides information for identifying fault conditions and performance
+        degradation of the foo functionality."</cref></t>
+
+      </section>
+
+      <section title="The Notifications Subtree">
+
+ <t><cref>[TEMPLATE TODO] describe the notifications defined in the MIB module, and
+        their purpose. Include a discussion of congestion control. You might
+want to discuss throttling as well. See RFC2914.</cref></t>
+
+      </section>
+
+      <section title="The Table Structures">
+
+<t><cref>[TEMPLATE TODO] Describe the tables in the MIB module, their purpose, and their
+reltionship to each other. If the row in one table is related to a row in 
+another table, what happens when one of the rows is deleted? Should the 
+related row be deleted as well? Consider both directions.</cref>
+</t>
+
+      </section>
+    </section>
+
+    <section title="Relationship to Other MIB Modules">
+
+<t><cref>[TEMPLATE TODO]: The narrative part should include a section that specifies the
+relationship (if any) of the MIB modules contained in this internet drafts to
+other standards, particularly to standards containing other MIB
+modules. If the MIB modules defined by the specification import
+definitions from other MIB modules or are always implemented in
+conjunction with other MIB modules, then those facts should be noted in
+the narrataive section, as should any special interpretations of objects
+in other MIB modules. Note that citations may NOT be put into the MIB
+module portions of the internet draft, but documents used for Imported items
+are Normative references, so the citations should exist in the narrative
+section of the internet draft. The preferred 
+way to fill in a REFERENCE clause in a MIB module is of the form: "Guidelines 
+for Writing an IANA Considerations Section in RFCs", RFC2434, section 2.3.</cref></t>
+
+      <section title="Relationship to the [TEMPLATE TODO] MIB">
+
+<t><cref>Example: The Interface MIB [RFC2863] requires that any
+MIB module which is an adjunct of the Interface MIB clarify specific
+areas within the Interface MIB. These areas were intentionally left
+vague in the Interface MIB to avoid over-constraining the MIB, thereby
+precluding management of certain media-types. Section 4 of [RFC2863] enumerates several
+areas which a media-specific MIB must clarify. The implementor is
+referred to [RFC2863] in order to understand the
+general intent of these areas.</cref></t>
+
+      </section>
+
+     <section title="MIB modules required for IMPORTS">
+
+<t><cref>[TEMPLATE TODO]: Citations are not permitted within a MIB module, but any
+module mentioned in an IMPORTS clause or document mentioned in a
+REFERENCE clause is a Normative reference, and must be cited someplace
+within the narrative sections. If there are imported items in the MIB
+module, such as Textual Conventions, that are not already cited, they
+can be cited in text here. Since relationships to other MIB modules
+should be described in the narrative text, this section is typically
+used to cite modules from which Textual Conventions are imported. Example: "The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], 
+SNMPv2-TC [RFC2579],
+SNMPv2-CONF [RFC2580], and IF-MIB [RFC2863]."</cref></t>
+
+      </section>
+    </section>
+
+    <section title="Definitions">
+ <t><cref>This section contains the actual MIB module(s).
+   These MIB modules MUST be written in SMIv2 [RFC2578] [RFC2579]
+   [RFC2580]. See Section 4 of RFC 4181 for guidelines on SMIv2 usage. 
+See Appendix C of RFC 4181 for suggested naming conventions.</cref></t>
+
+      <figure>
+        <artwork><![CDATA[
+[TEMPLATE TODO]: put your valid MIB module here. 
+A list of tools that can help automate the process of 
+checking MIB definitions can be found at the OPS 
+Area web site.]]></artwork>
+      </figure>
+    </section>
+
+    <section title="Security Considerations">
+
+<t><cref>[TEMPLATE TODO] Each internet draft that defines one or more MIB modules MUST
+contain a section that discusses security considerations relevant to
+those modules. This section MUST be patterned after the latest approved
+template (available at the OPS Area web site).
+</cref></t>
+
+<t><cref>[TEMPLATE TODO] if you have any read-write and/or read-create objects, please
+describe their specific sensitivity or vulnerability. RFC 2669 has a very good example.
+</cref></t>
+
+
+      <t>There are a number of management objects defined in this MIB module
+      with a MAX-ACCESS clause of read-write and/or read-create. Such objects
+      may be considered sensitive or vulnerable in some network environments.
+      The support for SET operations in a non-secure environment without
+      proper protection can have a negative effect on network operations.
+      These are the tables and objects and their
+      sensitivity/vulnerability:</t>
+
+      <t><list style="symbols">
+          <t></t>
+
+          <!--
+<t><cref>[TEMPLATE TODO] writeable tables and managed objects that could be especially disruptive
+if abused and the associated security risks should be spelled out.</cref></t>
+          -->
+        </list></t>
+
+<t><cref>[TEMPLATE TODO] else if there are no read-write or read-create objects in your MIB module,
+use the following boilerplate paragraph.</cref></t>
+
+      <t>There are no management objects defined in this MIB module that have
+      a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB
+      module is implemented correctly, then there is no risk that an intruder
+      can alter or create any management objects of this MIB module via direct
+      SNMP SET operations.</t>
+
+      <t><cref>For all MIB modules you must evaluate whether any readable objects
+      are sensitive or vulnerable (for instance, if they might reveal customer
+      information or violate personal privacy laws such as those of the
+      European Union if exposed to unathorized parties).</cref></t>
+
+      <t>Some of the readable objects in this MIB module (i.e., objects with a
+      MAX-ACCESS other than not-accessible) may be considered sensitive or
+      vulnerable in some network environments. It is thus important to control
+      even GET and/or NOTIFY access to these objects and possibly to even
+      encrypt the values of these objects when sending them over the network
+      via SNMP. These are the tables and objects and their
+      sensitivity/vulnerability: <list style="symbols">
+          <t></t>
+
+<t><cref>[TEMPLATE TODO] you should explicitly list by name any readable objects that
+are sensitive or vulnerable and the associated security risks should
+be spelled out.</cref></t>
+
+        </list></t>
+
+<t><cref>[TEMPLATE TODO] The following three boilerplate paragraphs
+should not be changed without very good reason. Changes will almost
+certainly require justification during IESG review.</cref></t>
+
+      <t>SNMP versions prior to SNMPv3 did not include adequate security.
+   Even if the network itself is secure (for example by using IPsec),
+   there is no control as to who on the secure network is
+   allowed to access and GET/SET (read/change/create/delete) the objects
+   in this MIB module.</t>
+
+<t>   Implementations SHOULD provide the security features described by the   
+   SNMPv3 framework (see [RFC3410]), and implementations claiming compliance 
+   to the SNMPv3 standard MUST include full support for authentication and 
+   privacy via the User-based Security Model (USM) [RFC3414] with the AES 
+   cipher algorithm [RFC3826]. Implementations MAY also provide support for
+   the Transport Security Model (TSM) [RFC5591] in combination with a secure 
+   transport such as SSH [RFC5592] or TLS/DTLS [RFC6353]. </t>
+
+      <t>Further, deployment of SNMP versions prior to SNMPv3 is NOT
+      RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable
+      cryptographic security. It is then a customer/operator responsibility to
+      ensure that the SNMP entity giving access to an instance of this MIB
+      module is properly configured to give access to the objects only to
+      those principals (users) that have legitimate rights to indeed GET or
+      SET (change/create/delete) them.</t>
+    </section>
+
+    <section title="IANA Considerations">
+
+<t><cref>[TEMPLATE TODO] In order to comply with IESG policy as set forth in
+http://www.ietf.org/ID-Checklist.html, every Internet-Draft that is
+submitted to the IESG for publication MUST contain an IANA
+Considerations section. The requirements for this section vary depending
+what actions are required of the IANA. See "Guidelines for Writing an IANA 
+Considerations Section in RFCs" [RFC2434]. and see RFC4181 section 3.5 for more
+information on writing an IANA clause for a MIB module internet draft.</cref></t>
+
+      <t>Option #1:</t>
+
+      <figure>
+        <preamble></preamble>
+
+        <artwork><![CDATA[
+     The MIB module in this document uses the following IANA-assigned
+     OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 
+      
+     Descriptor        OBJECT IDENTIFIER value
+     ----------        -----------------------
+     sampleMIB         { mib-2 XXX }
+      	]]></artwork>
+
+        <postamble></postamble>
+      </figure>
+
+      <t></t>
+
+      <t>Option #2:</t>
+
+      <t>Editor's Note (to be removed prior to publication): the IANA is
+      requested to assign a value for "XXX" under the 'mib-2' subtree and to
+      record the assignment in the SMI Numbers registry. When the assignment
+      has been made, the RFC Editor is asked to replace "XXX" (here and in the
+      MIB module) with the assigned value and to remove this note.</t>
+
+      <t>Note well: prior to official assignment by the IANA, an internet
+      draft MUST use placeholders (such as "XXX" above) rather than actual
+      numbers. See RFC4181 Section 4.5 for an example of how this is done in
+      an internet draft MIB module.</t>
+
+      <t>Option #3:</t>
+
+      <t>This memo includes no request to IANA.</t>
+    </section>
+
+    <!-- The Author's Addresses section will be generated automatically by XML2RFC 
+    from the front information. -->
+
+    <section title="Contributors">
+      <!--
+
+      <t><cref>[TEMPLATE TODO] This optional section can be used to mention contributors to your internet draft.</cref></t>
+      -->
+    </section>
+  </middle>
+
+  <back>
+
+    <!-- References Section -->
+
+    <!-- Section 4.7f of [RFC2223bis] specifies the requirements for the
+   references sections.  In particular, there MUST be separate lists of
+   normative and informative references, each in a separate section.
+   The style SHOULD follow that of recently published RFCs.
+
+   The standard MIB boilerplate available at
+  the OPS Area web site includes lists of
+   normative and informative references that MUST appear in all IETF
+   specifications that contain MIB modules.  If items from other MIB
+   modules appear in an IMPORTS statement in the Definitions section,
+   then the specifications containing those MIB modules MUST be included
+   in the list of normative references.  When items are imported from an
+   IANA-maintained MIB module the corresponding normative reference
+   SHALL reference the on-line version of that MIB module.  It is the
+   policy of the RFC Editor that all references must be cited in the
+   text;  such citations MUST appear in the overview section where
+   documents containing imported definitions (other than those already
+   mentioned in the MIB boilerplate) are required to be mentioned (cf.
+   Section 3.2).
+
+In general, each normative reference SHOULD reference the most recent
+version of the specification in question.
+-->
+
+    <references title="Normative References">
+        <!-- [TEMPLATE TODO] rfc2119, 2578, 2579, and 2580 are required to support MIB
+      module boilerplate text. -->
+
+      &rfc2119;
+
+      &rfc2578;
+
+      &rfc2579;
+
+      &rfc2580;
+
+    </references>
+
+    <references title="Informative References">
+
+<!--  RFC3410 is required to support the boilerplate text.-->
+      &rfc2223;
+      &rfc3410;
+
+     &rfc2629;
+
+       &rfc4181;
+
+    </references>
+    
+    <references title="URL References">
+<reference anchor="idguidelines">
+	<front>
+		<title>http://www.ietf.org/ietf/1id-guidelines.txt</title>
+		<author>
+			<organization>IETF Internet Drafts editor</organization>
+		</author>
+		<date year=""></date>
+	</front>
+</reference>
+<reference anchor="idnits">
+	<front>
+		<title>http://www.ietf.org/ID-Checklist.html</title>
+		<author>
+			<organization>IETF Internet Drafts editor</organization>
+		</author>
+		<date year=""></date>
+	</front>
+</reference>
+<reference anchor="xml2rfc">
+	<front>
+		<title>http://xml.resource.org</title>
+		<author>
+			<organization>XML2RFC tools and documentation</organization>
+		</author>
+		<date year=""></date>
+	</front>
+</reference>								
+<reference anchor="ops">
+	<front>
+		<title>http://www.ops.ietf.org</title>
+		<author>
+			<organization>the IETF OPS Area</organization>
+		</author>
+		<date year=""></date>
+	</front>
+</reference>		
+<reference anchor="ietf">
+	<front>
+		<title>http://tools.ietf.org</title>
+		<author>
+			<organization>IETF Tools Team</organization>
+		</author>
+		<date year=""></date>
+	</front>
+</reference>						
+     
+    </references>
+    <!--
+<section anchor="appendix" title="Appendix A">
+	<t>You can add appendices just as regular sections, the only
+difference is that they go under "back" element, and get letters 
+instead of numbers</t>
+</section>
+-->
+
+    <section title="Change Log ">
+      <t>Note to RFC Editor: if this document does not obsolete an existing RFC, 
+      please remove this appendix before publication as an RFC.</t>
+<!--
+      from draft 12 to draft 13
+      <t><list style="numbers">
+      <t></t>
+        </list></t>
+          -->
+    </section>
+
+    <section title="Open Issues">
+      <t>Note to RFC Editor: please remove this appendix before publication as an RFC.</t>
+           <!--
+		 <t><list style="numbers">
+          <t>Contributor addresses need to be updated</t>
+        </list></t>
+        -->
+    </section>
+
+    <!--
+$Id: mib-doc-template.xml,v 1.5 2008/04/08 17:39:56 H73653 Exp $
+
+  -->
+  </back>
+</rfc>