[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Mib template revisions



Hi,

Here's the latest revision of the XML source for the MIB template.
I don't include the output file because you can generate it yourself
(which will be a good debugging test).

Because the file has an <rfcedstyle> directive, you need to remove the
directive, or use the experimental version of the web service,
available via the "Living on the Edge" link of the main site.

David Harrington
dbharrington@comcast.net

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<!-- 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.

In the meantime therefore, we use an alternative valid-XML approach to includes, which unfortunately require that define your includes at the beginning of the file. Since the biggest benefit of includes is for references, this requires that your references be defined in ENTITY cluases here before being "included" and cited elsewhere in the file.
-->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY rfc0768 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml'>    
<!ENTITY rfc2119 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
      <!ENTITY rfc2578 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml'>
<!ENTITY rfc2579 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml'>
<!ENTITY rfc2580 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml'> 
<!ENTITY rfc2629 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY rfc2863 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml'>
<!ENTITY rfc3410 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml'>
<!ENTITY rfc3418 PUBLIC ''
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml'>
  <!ENTITY rfc4181 PUBLIC ''
      '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"?>

<!--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 documents.-->
<!-- throughout this template, the marker "ATTN" is used to indicate an element or text that requires replacement or removal. -->

<!-- Intellectual Property section -->
<!-- The Intellectual Property section will be generated automatically by XML2RFC, based on the ipr attribute in the rfc element. -->

<!-- ATTN: indicate which intellectual property notice to use per RFC3667, the intended status per RFC2026, and the document filename  -->
<!-- other categories: bcp, exp, historic, std -->





<rfc ipr="full3978" docName="draft-harrington-xml2rfc-mib-template-00d.txt" >
	<!--
	place for source control log here
  -->
<front>
<!-- ATTN: indicate the full document title and an abbreviated version to use in the page header. -->
<title abbrev="MIB Module Template">A Template for XML2RFC MIB Module Documents</title>

<!-- ATTN: see RFC2223 for guidelines regarding author names -->
<!-- copy this block as many times as needed, one for each author -->

		<author role="editor" initials="D" surname="Harrington" fullname="David Harrington" >
			<organization>Effective Software Consulting</organization>
			<address>
				<postal>
					<street>50 Harding Rd</street>
					<city>Portsmouth, NH 03801</city>
					<country>USA</country>
				</postal>

				<phone>+1 603 436 8634</phone>
				<email>dbharrington@comcast.net</email>
			</address>
		</author>

<!-- ATTN -->
<!-- month and day will be generated automatically-->

<date year="2005"/> 			

<!-- ATTN: IETF area is optional -->
<area>Operations &amp; Management Area</area>

<!-- WG name at the upperleft corner of the doc, IETF fine for individual submissions -->
<workgroup>Internet Engineering Task Force</workgroup>
		<keyword>Network Management</keyword>
		<keyword>Simple Network Management Protocol</keyword>
		<keyword>SNMP</keyword>
<!-- add additional keywords here for IETF website search engine -->

<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 SAMPLE protocol. [ATTN: describe what functionality will be managed using this MIB module, such as the SAMPLE protocol.]
        </t>
  <!-- ATTN - Remember, don't put any citations in the abstract, and expand your acronyms. -->
</abstract>


<note title="Foreword ">
<t >For updated information on MIB module guidelines and templates, see http://www.ops.ietf.org/.</t>
	<t>For information on writing internet drafts or RFCs, see http://www.ietf.org/ietf/1id-guidelines.txt and RFC2223(bis), and look at http://www.ietf.org/ID-Checklist.html for issues to note when writing
drafts.</t>
	<t>For information on XML2RFC, see RFC2629 <xref target="RFC2629"></xref>,
http://xml.resource.org/public/rfc/html/rfc2629.html and "bis":
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html.  Also see
http://xml.resource.org/authoring/README.html for 'rfc' option
strings.</t>
	<t>You don't need to have any other tools than a 'notepad'
or your favourite editor to write xml2rfc drafts.  You can use the web
interface at http://xml.resource.org for processing.  The benefit of using
xml editors is mostly catching those missing tags which the processor will
warn you about, but you don't need to worry about the editors when getting
started.</t>
	<t>This template is not meant to be a conclusive list of everything,
but summarize the often-needed basic features to get one started.</t>
<t>ATTN: please remove this Forward prior to publication.</t>
</note>
</front>
<middle>



<section title="Introduction">
<!-- It is good practice to echo the abstract in the Introduction, providing citations here. -->
     <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 SAMPLE protocol, defined in  <xref
target="RFC0768">"The SAMPLE Protocol"</xref> [ATTN: describe what functionality will be managed using this MIB module.]
        </t>
</section>


<!-- This section MUST contain a verbatim copy of the latest approved
   Internet-Standard Management Framework boilerplate, which is
   available on-line at http://www.ops.ietf.org/mib-boilerplate.html. -->
<!-- The following boilerplates have been copied from the official boilerplate, and should not be modified unless the boilerplate text at http;//ops.ietf.org/ has changed.-->
 <section title="The Internet-Standard Management Framework">
      <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"/>.
      </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"/>, STD 58, RFC 2579 <xref target="RFC2579"/>
        and STD 58, RFC 2580 <xref target="RFC2580"/>.
      </t>
</section>

<section title="Conventions"  >
     <!-- This boilerplate should be used if the following key words are used. -->
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
        RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this
        document, are to be interpreted as described in BCP 14, RFC
        2119 <xref target="RFC2119"/>.
      </t>



<!-- end conventions; -->
</section>

<!-- ********************************************* -->
<!-- The narrative part MUST include an overview section that describes
   the scope and field of application of the MIB modules defined by the
   specification and that specifies the relationship (if any) of these
   MIB modules to other standards, particularly to standards containing
   other MIB modules.  The narrative part SHOULD include one or more
   sections to briefly describe the structure of the MIB modules defined
   in the specification.

   If the MIB modules defined by the specification import definitions
   from other MIB modules (except for those defined in the SMIv2
documents [RFC2578] [RFC2579] [RFC2580]) or are always implemented in
   conjunction with other MIB modules, then those facts MUST be noted in
   the overview section, as MUST any special interpretations of objects
   in other MIB modules.  Note that citations may NOT be put into the MIB module portions of the document. For instance, so-called media-specific MIB
MIB module itself, but documents used for Imported items are Normative references, 
so the citations must exist in the narrative section of the document.
For example, some modules are always implemented in conjunction with the IF-MIB
   [RFC2863] and are REQUIRED to document how certain objects in the IF-
   MIB are used.  In addition, media-specific MIB modules that rely on
   the ifStackTable [RFC2863] and the ifInvStackTable [RFC2864] to
   maintain information regarding configuration and multiplexing of
   interface sublayers MUST contain a description of the layering model.
-->

<section title="Overview">
<t>This document  provides analysis of application performance as experienced by
   end-users.</t>

<t>   SAMPLE performance measurement measures the quality of service
   delivered to end-users by the SAMPLE Protocol.  With this perspective, a
   true end-to-end view of the IT infrastructure results, combining the
   performance of the SAMPLE Protocol as well as any positive or negative 
   interactions between multiple entities using the SAMPLE Protocol.</t>

<t>   Despite all the technically sophisticated ways in which networking
   and system resources can be measured, human end-users perceive only
   two things about an application: availability and responsiveness.
<list style="symbol">


     <t> Availability - The percentage of the time that the application is
      ready to give a user service.</t>

<t>      Responsiveness - The speed at which the application delivers the
      requested service.</t>
      </list>
</t>
<t>   A transaction is an action initiated by a user that starts and
   completes a distributed processing function.  A transaction begins
   when a user initiates a request for service (i.e., pushing a submit
   button) and ends when the work is completed (i.e., information is
   provided or a confirmation is delivered).  A transaction is the
   fundamental item measured by the SAMPLE MIB.</t>
<t >blah, blah, blah, blah ...</t>
</section>

<!-- Design Principles  -->
<!--
        <t>This section is here to remind authors of the Design Principles
         for SNMP MIB modules, and to demonstrate the use of lists </t>

        <t>To be consistent with IAB directives and good engineering
        practice, an explicit attempt was made to keep this MIB module
        as simple as possible.  This was accomplished by applying the
        following criteria to objects proposed for inclusion:</t>
      </t>
      <t>
        <list style="numbers">
          <t hangText="(1)">
            Start with a small set of essential objects and add only
            as objects are needed.
          </t>
          <t hangText="(2)">
            Require objects be essential for either fault or
            configuration management.
          </t>
          <t hangText="(3)">
            Consider evidence of current use and/or utility.
          </t>
          <t hangText="(4)">
            Limit the total number of objects.
          </t>
          <t hangText="(5)">
            Exclude objects which are simply derivable from others in
            this or other MIB modules. 
          </t>
          <t hangText="(6)">
            Avoid causing critical sections to be heavily
            instrumented.  The guideline that was followed is one
            counter per critical section per layer.
          </t>
          <t>Consider the requirements of a small footprint system, such as a set-top box as well as the expanded functionality beneficial to a large foootprint system. To the degree possible, costs associated with advanced functionality should be borne only by the systems implementing such functionality, and the overhead of advanced functionality should minimally impact systems which do not implement the advanced functionality.</t>
        </list>
      </t>
      </section>
-->    


<section title="Structure of the MIB Module">
<section title="Textual Conventions">

        <t >Generic and Common Textual Conventions can be found summarized at http://www.ops.ietf.org/mib-common-tcs.html </t>
</section>
        <t>
          Objects in this MIB module are arranged into groups.  Each
          group is organized as a set of related objects.  The overall
          structure and assignment of objects to their groups, and the intended purpose of each group, is shown
          below. 
        </t>
		       <section title="The sample Group">
          <t>
            This group contains the objects which are
            applicable to all types of entities implementing
            the SAMPLE protocol..
          </t>
          <t >This group provides information for identifying fault conditions and performance degradation.</t>
        </section>
        <section title="The sample999 Group">
          <t>
            This group contains the objects that denote the entity's
            state with respect to the sample999 features of the SAMPLE Protocol. Object s have been defined to enable/disable and control the Sample999 feature set, as well as to monitor the traffic transmitted or received via the Sample999 feature.
          </t>
          </section>
           <section title="The Notifications Group">
          <t>
            This group contains notifications to alert other entities to events which could alter the operational behavior of the entity in a network utilizing the SAMPLE Protocol. 
          </t>
        </section>
</section>
     <section title="Relationship to Other MIB Modules">
        <t>
          Some management objects defined in other MIB modules are
          applicable to an entity implementing this MIB.  In particular, it is 
          assumed that an entity implementing the SAMPLE-MIB module will also
          implement the 'system' group of the SNMPv2-MIB
          <xref target="RFC3418"/> and the 'interfaces' group of the
          IF-MIB <xref target="RFC2863"/>.
        </t>
        <section title="Relationship to the SNMPv2-MIB">
          <t>
            The 'system' group in the SNMPv2-MIB <xref target="RFC3418"/> is 
            defined as being mandatory for all systems, and the objects apply to the entity as a whole.
           The 'system' group provides identification of the management entity and certain other system-wide data. The SAMPLE-MIB does not duplicate those objects.
          </t>
        </section>
               <section title="Relationship to the IF-MIB">
          <t>
            In the SNMPv2-MIB <xref target="RFC3418"/>, the 'system'
            group is defined as being mandatory for all systems.
            Thus, those objects apply to the entity as a whole
            irrespective of whether the entity's sole functionality is
            bridging, or whether bridging is only a subset of the
            entity's functionality.
          </t>
        </section>
               <section title="MIB modules required for Imports">
<!-- if there are imported items in the MIB module, such as Textual Conventions,
which are not already cited, they can be cited in text here. 
Don't use this as a shortcut to not explain the relationship, if important. -->
<t>    The following MIB module IMPORTS objects from XXX-MIB [RFCxxxx],
    YYY-MIB [RFCyyy] and also REFERENCEs documents AAAA [RFCaaaa] and
    BBBB [RFCbbbb]
</t>
</section>
<!-- end narrative sections -->
</section>

<!-- Definitions section -->
<!-- This section contains the MIB module(s) defined by the specification.
   These MIB modules MUST be written in SMIv2 [RFC2578] [RFC2579]
   [RFC2580];  SMIv1 [RFC1155] [RFC1212] [RFC1215] has "Not Recommended"
   status [RFC3410] and is no longer acceptable in IETF MIB modules.

   See Section 4 of RFC 4181 for guidelines on SMIv2 usage.

	See Appendix C of RFC 4181 for suggested naming conventions

A list of tools that can help automate the process of checking mib definitions can be found at http://www.ops.ietf.org/mib-review-tools.html
 -->
   <section title="Definitions">
      <figure>
        <artwork>
SAMPLE-MIB DEFINITIONS ::= BEGIN

-- ---------------------------------------------------------- --
-- MIB for SAMPLE devices
-- ---------------------------------------------------------- --
IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
    Counter32, Integer32, TimeTicks, mib-2
        FROM SNMPv2-SMI
    TEXTUAL-CONVENTION, MacAddress
        FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
        FROM SNMPv2-CONF
    InterfaceIndex FROM IF-MIB
    ;

sampleMIB MODULE-IDENTITY
    LAST-UPDATED "200410220000Z"
    ORGANIZATION "IETF SAMPLE MIB Working Group"
    CONTACT-INFO
        "Email: ietfmibs@ops.ietf.org

                 <!-- ATTN: name --> (Editor)
                 Tel: 
          Email: 
         Postal: 
                 

         Send comments to &lt;ietfmibs@ops.ietf.org&gt;"
    DESCRIPTION
        "A sample MIB module for managing devices that support
        a SAMPLE protocol.

        Copyright (C) The Internet Society (2005). This version of
        this MIB module is part of RFC XXXX; see the RFC itself for
        full legal notices.
-- RFC Ed.: replace XXXX with actual RFC number and remove this note
         "
       REVISION     "200509020000Z"         -- 27 September 2005

    DESCRIPTION
         "Third revision, published as part of RFC XXXX. 

         The MIB module has been converted to SMIv2 format. 
         Conformance statements have been added and some 
         description and reference clauses have been updated.

         The object sampleObject999 was added to 
         support SAMPLE v3 and the permissible values of 
         samplePriority and samplePortPriority have been
         clarified for entities supporting SAMPLE v2.

         The interpretation of sampleLastChange
         has been clarified for entities supporting the foo feature
         of SAMPLE v2."
    REVISION     "199307310000Z"
    DESCRIPTION
         "Second revision, published as part of RFC BBBB."
    REVISION     "199112310000Z"
    DESCRIPTION
         "Initial revision, published as part of RFC AAAA."
    ::= { mib-2 YYYY }

-- ---------------------------------------------------------- --
-- Suggested OID layout
-- ---------------------------------------------------------- --
sampleNotifications    OBJECT IDENTIFIER ::= { sampleMIB 0 }
sampleObjects           OBJECT IDENTIFIER ::= { sampleMIB 1 }
sampleConformance  OBJECT IDENTIFIER ::= { sampleMIB 2 }

sampleCompliances   OBJECT IDENTIFIER ::= { sampleConformance 1 }
sampleGroups           OBJECT IDENTIFIER ::= { sampleConformance 2 }

-- ---------------------------------------------------------- --
-- Textual Conventions
-- ---------------------------------------------------------- --
-- All representations of MAC addresses in this MIB Module use,
-- as a textual convention, the data type MacAddress, defined in
-- SNMPv2-TC.

-- Similarly, all representations of Sample-Id in this MIB
-- module use, as a textual convention, the data type:

SampleId ::= TEXTUAL-CONVENTION
    STATUS      current
    DESCRIPTION
        "The Sample-Identifier as used in the Sample
        Protocol to uniquely identify an entity.  Its first two
        octets (in network byte order) contain a sample value
        and its last 6 octets contain the MAC address used to
        refer to an entity in a unique fashion (typically, the
        numerically smallest MAC address of all ports on the
        entity)."
    SYNTAX      OCTET STRING (SIZE (8))


-- ---------------------------------------------------------- --
-- the sample1  group
-- ---------------------------------------------------------- --
sample1  OBJECT IDENTIFIER ::= { sampleObjects 1 }

sample1Address OBJECT-TYPE

    SYNTAX      MacAddress
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The MAC address used by this entity when it must be
        referred to in a unique fashion.   It is recommended
        that this be the numerically smallest MAC address of all
        ports that belong to this entity.  However it is only
        required to be unique.  When concatenated with
        samplePriority a unique Sample Identifier is formed
        which is used in the Sample Protocol."
    REFERENCE
        "RFC CCCC clauses 14.4.1.1.3 and 7.12.5"
    ::= { sample1 1 }


-- ---------------------------------------------------------- --
-- the sample999  group
-- ---------------------------------------------------------- --
sample999  OBJECT IDENTIFIER ::= { sampleObjects 1 }

sample999Address OBJECT-TYPE

    SYNTAX      MacAddress
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The MAC address used by this entity when it must be
        referred to in a unique fashion.   It is recommended
        that this be the numerically smallest MAC address of all
        ports that belong to this entity.  However it is only
        required to be unique.  When concatenated with
        samplePriority a unique Sample Identifier is formed
        which is used in the Sample Protocol."
    REFERENCE
        "RFC CCCC clauses 14.4.1.1.3 and 7.12.5"
    ::= { sample999 1 }


-- ---------------------------------------------------------- --
-- Notifications for use by Sample entities
-- ---------------------------------------------------------- --


sampleNewRoot NOTIFICATION-TYPE
    -- OBJECTS     { }
    STATUS      current
    DESCRIPTION
        "This notification indicates that the sending entity has
        become the new root of the Sample Protocol coordination."
    ::= { sampleNotifications 1 }

sampleLastChange NOTIFICATION-TYPE
    -- OBJECTS     { }
    STATUS      current
    DESCRIPTION
        "This notification is sent by an entity when any of
        its configured ports transitions from the Sample1 state
        to the Sample2 state, or from the Sample2 state to
        the Sample1 state.  The notification is not sent if a 
        sampleNewRoot notification is sent for the same transition."
    ::= { sampleNotifications 2 }


- ---------------------------------------------------------- --
-- Sample MIB - Conformance Information
-- ---------------------------------------------------------- --


- ---------------------------------------------------------- --
-- the sample999 group
-- ---------------------------------------------------------- --

sample1Group OBJECT-GROUP
    OBJECTS {
        sample1Address
    }
    STATUS      current
    DESCRIPTION
        "Sample1 information for this device."
    ::= { sampleGroups 1 }

- ---------------------------------------------------------- --
-- the sample999 group
-- ---------------------------------------------------------- --

sample999Group OBJECT-GROUP
    OBJECTS {
        sample999Address
    }
    STATUS      current
    DESCRIPTION
        "Sample999  information for this device."
    ::= { sampleGroups 2 }


-- ---------------------------------------------------------- --
-- The Sample Notification Group
-- ---------------------------------------------------------- --

sampleNotificationGroup NOTIFICATION-GROUP
    NOTIFICATIONS {
        SampleNewRoot,
        sampleLastChange
    }
    STATUS      current
    DESCRIPTION
        "Group of objects describing notifications."
    ::= { sampleGroups 2 }

-- ---------------------------------------------------------- --
-- compliance statements
-- ---------------------------------------------------------- --

sampleFullCompliance MODULE-COMPLIANCE
    STATUS      current
    DESCRIPTION
        "The compliance statement for device support of Sample
        services.  This supports the Sample999 features of the Sample 
        Protocol"

    MODULE
        MANDATORY-GROUPS {
            sample1Group,
            sample999Group,
            sampleNotificationsGroup
        }
        
    GROUP   sample1Group
    DESCRIPTION
        "Implementation of this group is mandatory."
        
   GROUP   sample1Group
    DESCRIPTION
        "Implementation of this group is mandatory."

    GROUP sampleNotificationsGroup
    DESCRIPTION
        "Implementation of this group is mandatory."
    ::= { sampleCompliances 1 }
    
    sampleBasicCompliance MODULE-COMPLIANCE
    STATUS      current
    DESCRIPTION
        "The compliance statement for devices supporting only 
        Sample1 management"

    MODULE
        MANDATORY-GROUPS {
            sample1Group
        }

    GROUP   sample1Group
    DESCRIPTION
        "Implementation of this group is mandatory for entities
        that support the Sample1 Protocol."

    ::= { sampleCompliances 2 }

END
        </artwork>
      </figure>
    </section>


 




<!-- Each specification 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 http://www.ops.ietf.org/mib-security.html).
   In particular, writeable MIB objects that could be especially
   disruptive if abused MUST be explicitly listed by name and the
   associated security risks MUST be spelled out;  similarly, readable
   MIB objects that contain especially sensitive information or that
   raise significant privacy concerns MUST be explicitly listed by name
   and the reasons for the sensitivity/privacy concerns MUST be
   explained.  If there are no risks/vulnerabilities for a specific
   category of MIB objects, then that fact MUST be explicitly stated.
   Failure to mention a particular category of MIB objects will not be
   equated to a claim of no risks/vulnerabilities in that category;
   rather, it will be treated as an act of omission and will result in
   the document being returned to the author for correction.  Remember
   that the objective is not to blindly copy text from the template, but
   rather to think and evaluate the risks/vulnerabilities and then
   state/document the result of this evaluation.
-->
<section title="Security Considerations">
	<!-- Remember to consider security from the start.-->

	<!-- 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. -->

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

    <list style="symbols" >
	<!-- list the tables and objects and state why they are sensitive -->
	<t></t>
    </list>
</t>
	<!-- else if there are no read-write objects in your MIB module -->

   <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>



	<!--.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)  -->


  <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" >
	<!-- list the tables and objects and state why they are sensitive -->
	<t></t>
    </list>
</t>

		<!-- discuss what security the protocol used to carry the information should have -->
		
	<t>SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec),
   even then, 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> It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).</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">
<!-- 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 the "Guidelines for MIB Authors and Reviewers" <xref="guidelines"> for more information on writing an IANA clause for a MIB module document.-->
<t>Option #1:</t>
<t>   
<figure>
	<preamble></preamble>
	<artwork>
     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>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, a draft
   document MUST use placeholders (such as "XXX" above) rather than
   actual numbers.  See Section 4.5 for an example of how this is done
   in a draft MIB module.
</t>

<t>Option #3:</t>
<!-- If no IANA work is required, an explicit note must be included.-->
	<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>This work is based on contributions from the MIb Doctors, including Dave Perkins and C.M.Heard for the section organization and Bert Wijnen for the 'include' statement format.</t>
</section>
<section title="Acknowledgements">
	<t>Thanks to Marshall Rose for developing the XML2RFC format. Pekka Savola developed an XML2RFC template, upon which the MIB module template is based.</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
   http://www.ops.ietf.org/mib-boilerplate.html 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 point to 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 those already
   mentioned in the MIB boilerplate) are required to be mentioned (cf.
   Section 3.2).

In general, each normative reference SHOULD point to the most recent
   version of the specification in question.
-->
<!-- references split to informative and normative -->
<references  title="Normative References">

<!-- start of normative references that are required only to support this template, and which can be removed from the final document. -->

&rfc2629;
&rfc2863;
&rfc3418;  
&rfc0768;
  
<!-- end of normative references that are required only to support this template; Remove from the final document. -->

<!-- start of normative references that are required to support the boilerplate text. -->


&rfc2119;
&rfc2578;
&rfc2579;  
&rfc2580;
 
	
<!-- end of references that are required to support the boilerplate text. -->
<!-- ATTN: start of normative references samples. Replace with your own. -->

<!-- end of normative references samples. -->

</references>
<references title="Informative References">
<!-- start of informative references that are required to support the boilerplate text. -->
&rfc3410;

<!-- end of informative references that are required to support the boilerplate text. -->
</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="Changes from RFC BBBB  (the previous RFC for this specification)">
      <t>
        The following changes have been made from RFC BBBB.
      </t>
      <t>
        <list style="numbers">
        <t>  Translated the MIB definitions to use SMIv2. This includes
          the introduction of conformance statements. ASN.1 type
          definitions have been converted into textual-conventions
          and several units clauses were added. </t>
        <t>The sample999 group was added.</t>
        <t> Permissible values for samplePriority have been clarified. </t>
        <t> Interpretation of sampleLastChange has been
          clarified. </t>
        <t>  Updated the introductionary boilerplate text, the security
          considerations section and the references to comply with the
          current IETF standards and guidelines. </t>
         <t> Additions and clarifications in various description clauses. </t>
      </list>
      </t>
    </section>
 

    <section title="Open Issues">
      <t>
        This list of open issues should be cleared and removed before
        this document hits the IESG.
      </t>
      <t>
        <list style="numbers">
          <t>
            Contributor addresses need to be updated
          </t>
          <t>
            The interaction of sample1 and sample999 behaviors needs to be clarified.
          </t>
      </list>
      </t>
    </section>

</back>

</rfc>