asciidoctor-rfc 0.9.0 → 0.9.1

data/spec/examples/hoffmanv2.xml.orig.txt

@@ -0,0 +1,280 @@
+
+
+
+
+Imaginary WG                                                    C. Smith
+Internet-Draft                                                        EC
+Updates: 1234, 5678 (if approved)                               K. Jones
+Intended status: Standards Track                          September 2014
+Expires: March 5, 2015
+
+
+             An Example of Using XML for an Internet Draft
+                        draft-example-of-xml-00
+
+Abstract
+
+   This is an example of an abstract.  It is a short paragraph that
+   gives an overview of the document in order to help the reader
+   determine whether or not they are interested in reading further.
+
+Disclaimer
+
+   This isn't a real RFC, just an example.
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   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
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on March 5, 2015.
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+
+
+
+Smith & Jones             Expires March 5, 2015                 [Page 1]
+
+Internet-Draft                 XML Example                September 2014
+
+
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+1.  Introduction
+
+   This is the first paragraph of the introduction to this document.
+   This introduction is probably much shorter than it would be for a
+   real Internet Draft.
+
+   Something to note about this paragraph is that it has a pointer to
+   Section 2, and one to Figure 1, both of which appear later in the
+   document.
+
+1.1.  Terminology
+
+   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 [RFC2119].
+
+2.  The Protocol Being Described
+
+   This is a reference to [RFC6949].  Actually, the reference itself is
+   not all that interesting, but the way that the reference is
+   incorporated is.  Note that the inclusion of RFC 2119 was done at the
+   top of the XML, while the information for RFC 6949 is done directly
+   in the references section.
+
+   The IETF web site [1] is _quite_ *nice*, "isn't it"?  Unlike other
+   web sites, it doesn't use
+
+
+   gratuitous vertical space.
+
+3.  Basic Lists
+
+   Bulleted lists are good for items that are not ordered:
+
+   o  This is the first item.
+
+   o  This is the second item.  Here comes a sub-list:
+
+      *  This is the first sub-item.
+
+      *  This is the second sub-item
+         and some more detail on the second sub-item.
+
+   o  This is the item after the sub-list.
+
+
+
+Smith & Jones             Expires March 5, 2015                 [Page 2]
+
+Internet-Draft                 XML Example                September 2014
+
+
+   Numbered lists are good for items that are ordered:
+
+   1.  This is the first item.
+
+   2.  This is the second item.  Here comes a sub-list, but with
+       letters:
+
+       A.  This is the first sub-item.
+
+       B.  This is the second sub-item
+
+   3.  This is the item after the sub-list.
+
+   And an example of hanging indent.
+
+   Trees          These are bigger plants
+
+   Lichen         These are smaller plants
+
+   And the always-interesting "format" for lists.
+
+   --1--  An element that gets a funny bullet.
+
+4.  Figures
+
+   The following is a figure with a caption.  Also, it uses the
+   ampersand (&) and less than (<) characters in the example text.
+
+         The ampersand (&) and
+         less than (<) are two characters
+         that need escaping.
+
+                       Figure 1: This could be haiku
+
+   Here are two short figures with no titles and with odd alignment.
+
+                       This might appear in the center.
+
+                                        This might appear right-aligned.
+
+   Here is a figure that is actually pulled from somewhere else.
+
+5.  Tables
+
+   The following is a table example.
+
+
+
+
+
+
+Smith & Jones             Expires March 5, 2015                 [Page 3]
+
+Internet-Draft                 XML Example                September 2014
+
+
+                These are sometimes called "inert" gasses.
+
+       +---------+--------------------------------+---------------+
+       | Name    |             Symbol             | Atomic Number |
+       +---------+--------------------------------+---------------+
+       | Helium  |               He               |       2       |
+       |         |                                |               |
+       | Neon    |               Ne               |       10      |
+       |         |                                |               |
+       | Argon   |               Ar               |       18      |
+       |         |                                |               |
+       | Krypton |               Kr               |       36      |
+       |         |                                |               |
+       | Xenon   |               Xe               |       54      |
+       |         |                                |               |
+       | Radon   |               Rn               |       86      |
+       +---------+--------------------------------+---------------+
+
+                           Source: Chemistry 101
+
+                              The Noble Gases
+
+   The following is a right-aligned table with "full" (but not "all")
+   lines between cells.
+
+                                                  +-----------+--------+
+                                                  | Time      |   Mood |
+                                                  +-----------+--------+
+                                                  | Morning   | Happy! |
+                                                  |           |        |
+                                                  | Afternoon | Happy! |
+                                                  |           |        |
+                                                  | Evening   | Somber |
+                                                  +-----------+--------+
+
+6.  IANA Considerations
+
+   None.
+
+7.  Security Considerations
+
+   There are no security considerations for an imaginary Internet Draft.
+
+8.  Acknowledgements
+
+   Some of the things included in this draft came from Elwyn Davies'
+   templates.
+
+
+
+
+Smith & Jones             Expires March 5, 2015                 [Page 4]
+
+Internet-Draft                 XML Example                September 2014
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+9.2.  Informative References
+
+   [RED]      Floyd, S. and V. Jacobson, "Random Early Detection (RED)
+              gateways for Congestion Avoidance", IEEE/ACM Transactions
+              on Networking 1(4) 397--413, August 1993,
+              <http://www.aciri.org/floyd/papers/early.pdf>.
+
+   [RFC6949]  Flanagan, H. and N. Brownlee, "RFC Series Format
+              Requirements and Future Development", RFC 6949, May 2013.
+
+              This is a primary reference work.
+
+9.3.  URIs
+
+   [1] http://www.ietf.org
+
+Index
+
+   I
+      Introduction
+         verbiage  2
+
+Authors' Addresses
+
+   Chris Smith
+   ExampleCorp
+   123 Exemplar Way
+   Anytown, California  95060
+   US
+
+   Phone: +1 123-456-7890
+   Fax:   +1 123-456-7890
+   Email: chrissmith@example.com
+   URI:   http://www.example.com/corporate/
+
+
+   Kim Jones
+
+   Email: jk@lmn.op
+
+
+
+Smith & Jones             Expires March 5, 2015                 [Page 5]

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

@@ -0,0 +1,672 @@
+
+
+
+
+Internet Engineering Task Force                             Y. Name, Ed.
+Internet-Draft                                        Editor affiliation
+Intended status: Historic                                January 1, 2008
+Expires: July 4, 2008
+
+
+                     Your MIB module document name
+                   Your MIB Document name here rev07
+
+Abstract
+
+   [[CREF1: 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 &
+   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.]]
+
+   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].
+
+   [[CREF2: [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. ]]
+
+Foreword to template users
+
+   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.
+
+   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.
+
+   For updated information on MIB module guidelines and templates, see
+   [RFC4181] and the OPS Area web page and wiki.
+
+
+
+
+
+Name                      Expires July 4, 2008                  [Page 1]
+
+Internet-Draft        Your MIB Module document name         January 2008
+
+
+   For information on writing internet drafts or RFCs, see
+   http://www.ietf.org/ietf/1id-guidelines.txt and RFC2223(bis)
+   [RFC2223], and look at http://www.ietf.org/ID-Checklist.html for
+   issues to note when writing drafts.
+
+   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.
+
+   An XML2RFC template is also available.  For information on XML2RFC,
+   see RFC2629 [RFC2629], 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.
+
+   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.
+
+   [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.
+
+   [TEMPLATE TODO] Remove all page headings from the template document,
+   and replace them with the appropriate headings for your internet
+   draft.
+
+Note to RFC Editor re: [TEMPLATE TODO] markers
+
+   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.
+
+
+
+
+
+
+Name                      Expires July 4, 2008                  [Page 2]
+
+Internet-Draft        Your MIB Module document name         January 2008
+
+
+Status of This Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   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
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   This Internet-Draft will expire on July 4, 2008.
+
+Copyright Notice
+
+   Copyright (c) 2008 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  The Internet-Standard Management Framework  . . . . . . . . .   4
+   3.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
+   5.  Structure of the MIB Module . . . . . . . . . . . . . . . . .   5
+     5.1.  Textual Conventions . . . . . . . . . . . . . . . . . . .   5
+     5.2.  The [TEMPLATE TODO] Subtree . . . . . . . . . . . . . . .   5
+     5.3.  The Notifications Subtree . . . . . . . . . . . . . . . .   5
+     5.4.  The Table Structures  . . . . . . . . . . . . . . . . . .   6
+   6.  Relationship to Other MIB Modules . . . . . . . . . . . . . .   6
+     6.1.  Relationship to the [TEMPLATE TODO] MIB . . . . . . . . .   6
+     6.2.  MIB modules required for IMPORTS  . . . . . . . . . . . .   6
+   7.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   7
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
+
+
+
+Name                      Expires July 4, 2008                  [Page 3]
+
+Internet-Draft        Your MIB Module document name         January 2008
+
+
+   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
+   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   9
+   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
+     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
+     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
+     11.3.  URL References . . . . . . . . . . . . . . . . . . . . .  10
+   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  12
+   Appendix B.  Open Issues  . . . . . . . . . . . . . . . . . . . .  12
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12
+
+1.  Introduction
+
+   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].
+
+   [[CREF3: [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.]]
+
+2.  The Internet-Standard Management Framework
+
+   [[CREF4: 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.]]
+
+   For a detailed overview of the documents that describe the current
+   Internet-Standard Management Framework, please refer to section 7 of
+   RFC 3410 [RFC3410].
+
+   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 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
+   [RFC2580].
+
+
+
+
+
+
+Name                      Expires July 4, 2008                  [Page 4]
+
+Internet-Draft        Your MIB Module document name         January 2008
+
+
+3.  Conventions
+
+   [[CREF5: [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. ]]
+
+   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
+   [RFC2119].
+
+4.  Overview
+
+   [[CREF6: [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.  ]]
+
+5.  Structure of the MIB Module
+
+   [[CREF7: [TEMPLATE TODO] The narrative part SHOULD include one or
+   more sections to briefly describe the structure of the MIB modules
+   defined in the specification.]]
+
+5.1.  Textual Conventions
+
+   [[CREF8: [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.]]
+
+5.2.  The [TEMPLATE TODO] Subtree
+
+   [[CREF9: [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."]]
+
+5.3.  The Notifications Subtree
+
+   [[CREF10: [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.]]
+
+
+
+
+Name                      Expires July 4, 2008                  [Page 5]
+
+Internet-Draft        Your MIB Module document name         January 2008
+
+
+5.4.  The Table Structures
+
+   [[CREF11: [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.]]
+
+6.  Relationship to Other MIB Modules
+
+   [[CREF12: [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.]]
+
+6.1.  Relationship to the [TEMPLATE TODO] MIB
+
+   [[CREF13: 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.]]
+
+6.2.  MIB modules required for IMPORTS
+
+   [[CREF14: [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
+
+
+
+
+Name                      Expires July 4, 2008                  [Page 6]
+
+Internet-Draft        Your MIB Module document name         January 2008
+
+
+   objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF
+   [RFC2580], and IF-MIB [RFC2863]."]]
+
+7.  Definitions
+
+   [[CREF15: 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.]]
+
+   [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.
+
+8.  Security Considerations
+
+   [[CREF16: [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).  ]]
+
+   [[CREF17: [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.  ]]
+
+   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:
+
+   o
+
+   [[CREF18: [TEMPLATE TODO] else if there are no read-write or read-
+   create objects in your MIB module, use the following boilerplate
+   paragraph.]]
+
+   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.
+
+
+
+
+
+Name                      Expires July 4, 2008                  [Page 7]
+
+Internet-Draft        Your MIB Module document name         January 2008
+
+
+   [[CREF19: 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).]]
+
+   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:
+
+   o
+
+   o  [[CREF20: [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.]]
+
+   [[CREF21: [TEMPLATE TODO] The following three boilerplate paragraphs
+   should not be changed without very good reason.  Changes will almost
+   certainly require justification during IESG review.]]
+
+   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.
+
+   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].
+
+   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.
+
+
+
+
+
+
+Name                      Expires July 4, 2008                  [Page 8]
+
+Internet-Draft        Your MIB Module document name         January 2008
+
+
+9.  IANA Considerations
+
+   [[CREF22: [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.]]
+
+   Option #1:
+
+        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 }
+
+   Option #2:
+
+   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.
+
+   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.
+
+   Option #3:
+
+   This memo includes no request to IANA.
+
+10.  Contributors
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+
+
+Name                      Expires July 4, 2008                  [Page 9]
+
+Internet-Draft        Your MIB Module document name         January 2008
+
+
+   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
+              Schoenwaelder, Ed., "Structure of Management Information
+              Version 2 (SMIv2)", STD 58, RFC 2578,
+              DOI 10.17487/RFC2578, April 1999,
+              <https://www.rfc-editor.org/info/rfc2578>.
+
+   [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
+              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
+              STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999,
+              <https://www.rfc-editor.org/info/rfc2579>.
+
+   [RFC2580]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
+              Schoenwaelder, Ed., "Conformance Statements for SMIv2",
+              STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999,
+              <https://www.rfc-editor.org/info/rfc2580>.
+
+11.2.  Informative References
+
+   [RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC Authors",
+              RFC 2223, DOI 10.17487/RFC2223, October 1997,
+              <https://www.rfc-editor.org/info/rfc2223>.
+
+   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
+              DOI 10.17487/RFC2629, June 1999,
+              <https://www.rfc-editor.org/info/rfc2629>.
+
+   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
+              "Introduction and Applicability Statements for Internet-
+              Standard Management Framework", RFC 3410,
+              DOI 10.17487/RFC3410, December 2002,
+              <https://www.rfc-editor.org/info/rfc3410>.
+
+   [RFC4181]  Heard, C., Ed., "Guidelines for Authors and Reviewers of
+              MIB Documents", BCP 111, RFC 4181, DOI 10.17487/RFC4181,
+              September 2005, <https://www.rfc-editor.org/info/rfc4181>.
+
+11.3.  URL References
+
+   [idguidelines]
+              IETF Internet Drafts editor,
+              "http://www.ietf.org/ietf/1id-guidelines.txt".
+
+   [idnits]   IETF Internet Drafts editor,
+              "http://www.ietf.org/ID-Checklist.html".
+
+   [ietf]     IETF Tools Team, "http://tools.ietf.org".
+
+   [ops]      the IETF OPS Area, "http://www.ops.ietf.org".
+
+
+
+Name                      Expires July 4, 2008                 [Page 10]
+
+Internet-Draft        Your MIB Module document name         January 2008
+
+
+   [xml2rfc]  XML2RFC tools and documentation,
+              "http://xml.resource.org".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Name                      Expires July 4, 2008                 [Page 11]
+
+Internet-Draft        Your MIB Module document name         January 2008
+
+
+Appendix A.  Change Log
+
+   Note to RFC Editor: if this document does not obsolete an existing
+   RFC, please remove this appendix before publication as an RFC.
+
+Appendix B.  Open Issues
+
+   Note to RFC Editor: please remove this appendix before publication as
+   an RFC.
+
+Author's Address
+
+   Editor Name (editor)
+   Editor affiliation
+   Editor affiliation address
+   Editor affiliation address
+   Editor affiliation address
+
+   Phone: Editor address
+   EMail: Editor email
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Name                      Expires July 4, 2008                 [Page 12]