[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Updated xml2rfc
Hi,
A new experimental version of xml2rfc is available online at
http://xml.resource.org/experimental.html
It is being updated to meet some of the rfc2223bis requirements. There
is a directive to use the rfceditor style: <?rfc rfcedstyle="yes">,
and it handles some issues such as when to use two spaces, whether to
capitalize "this" in a section header, how to spell acknowledgements,
etc. to meet the style choices of the RFC Editor.
It allows appendices before the references, and moved Author's Address
to just before the IPR statement. The References sections are still
numbered (which looks really weird with appendices in the middle. ;-)
I updated my template and tested this version. See what you think
about this output?
David Harrington
dbharrington@comcast.net
Internet Engineering Task Force D. Harrington, Ed.
Internet-Draft Effective Software Consulting
Expires: April 1, 2006 September 28, 2005
A Template for XML2RFC MIB Module Documents
draft-harrington-xml2rfc-mib-template-00.txt
Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 1, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
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.]
Foreword
For updated information on MIB module guidelines and templates, see
Harrington Expires April 1, 2006 [Page 1]
Internet-Draft MIB Module Template September 2005
http://www.ops.ietf.org/.
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.
For information on XML2RFC, see RFC2629(bis),
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.
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.
This template is not meant to be a conclusive list of everything, but
summarize the often-needed basic features to get one started.
ATTN: please remove this Forward prior to publication.
Harrington Expires April 1, 2006 [Page 2]
Internet-Draft MIB Module Template September 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Internet-Standard Management Framework . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 5
5.1. Textual Conventions . . . . . . . . . . . . . . . . . . . 5
5.2. The sample Group . . . . . . . . . . . . . . . . . . . . . 5
5.3. The sample999 Group . . . . . . . . . . . . . . . . . . . 5
5.4. The Notifications Group . . . . . . . . . . . . . . . . . 5
6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 6
6.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . 6
6.2. Relationship to the IF-MIB . . . . . . . . . . . . . . . . 6
6.3. MIB modules required for Imports . . . . . . . . . . . . . 6
7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from RFC BBBB (the previous RFC for this
specification) . . . . . . . . . . . . . . . . . . . 14
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Harrington Expires April 1, 2006 [Page 3]
Internet-Draft MIB Module Template September 2005
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 SAMPLE protocol, defined in "The SAMPLE
Protocol" [RFC_CCCC] [ATTN: describe what functionality will be
managed using this MIB module.]
2. The Internet-Standard Management Framework
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].
3. Conventions
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 [RFC2119].
4. Overview
This document provides analysis of application performance as
experienced by end-users.
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.
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.
Harrington Expires April 1, 2006 [Page 4]
Internet-Draft MIB Module Template September 2005
Availability - The percentage of the time that the application is
ready to give a user service.
Responsiveness - The speed at which the application delivers the
requested service.
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.
blah, blah, blah, blah ...
5. Structure of the MIB Module
5.1. Textual Conventions
Generic and Common Textual Conventions can be found summarized at
http://www.ops.ietf.org/mib-common-tcs.html
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.
5.2. The sample Group
This group contains the objects which are applicable to all types of
entities implementing the SAMPLE protocol..
This group provides information for identifying fault conditions and
performance degradation.
5.3. The sample999 Group
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.
5.4. The Notifications Group
This group contains notifications to alert other entities to events
which could alter the operational behavior of the entity in a network
Harrington Expires April 1, 2006 [Page 5]
Internet-Draft MIB Module Template September 2005
utilizing the SAMPLE Protocol.
6. Relationship to Other MIB Modules
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 [RFC3418] and the 'interfaces'
group of the IF-MIB [RFC2863].
6.1. Relationship to the SNMPv2-MIB
The 'system' group in the SNMPv2-MIB [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.
6.2. Relationship to the IF-MIB
In the SNMPv2-MIB [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.
6.3. MIB modules required for Imports
The following MIB module IMPORTS objects from XXX-MIB [RFCxxxx], YYY-
MIB [RFCyyy] and also REFERENCEs documents AAAA [RFCaaaa] and BBBB
[RFCbbbb]
7. Definitions
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
Harrington Expires April 1, 2006 [Page 6]
Internet-Draft MIB Module Template September 2005
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
(Editor)
Tel:
Email:
Postal:
Send comments to <ietfmibs@ops.ietf.org>"
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"
Harrington Expires April 1, 2006 [Page 7]
Internet-Draft MIB Module Template September 2005
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
Harrington Expires April 1, 2006 [Page 8]
Internet-Draft MIB Module Template September 2005
"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 }
Harrington Expires April 1, 2006 [Page 9]
Internet-Draft MIB Module Template September 2005
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
-- ---------------------------------------------------------- --
Harrington Expires April 1, 2006 [Page 10]
Internet-Draft MIB Module Template September 2005
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
Harrington Expires April 1, 2006 [Page 11]
Internet-Draft MIB Module Template September 2005
MANDATORY-GROUPS {
sample1Group
}
GROUP sample1Group
DESCRIPTION
"Implementation of this group is mandatory for entities
that support the Sample1 Protocol."
::= { sampleCompliances 2 }
END
8. Security Considerations
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
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.
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
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.
Harrington Expires April 1, 2006 [Page 12]
Internet-Draft MIB Module Template September 2005
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).
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.
9. IANA Considerations
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, 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.
Option #3:
This memo includes no request to IANA.
Harrington Expires April 1, 2006 [Page 13]
Internet-Draft MIB Module Template September 2005
10. Contributors
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.
11. Acknowledgements
Thanks to Marshall Rose for developing the XML2RFC format. Pekka
Savola developed an XML2RFC template, upon which the MIB module
template is based.
Appendix A. Changes from RFC BBBB (the previous RFC for this
specification)
The following changes have been made from RFC BBBB.
1. 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.
2. The sample999 group was added.
3. Permissible values for samplePriority have been clarified.
4. Interpretation of sampleLastChange has been clarified.
5. Updated the introductionary boilerplate text, the security
considerations section and the references to comply with the
current IETF standards and guidelines.
6. Additions and clarifications in various description clauses.
Appendix B. Open Issues
This list of open issues should be cleared and removed before this
document hits the IESG.
1. Contributor addresses need to be updated
2. The interaction of sample1 and sample999 behaviors needs to be
clarified.
Harrington Expires April 1, 2006 [Page 14]
Internet-Draft MIB Module Template September 2005
12. References
12.1. Normative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", BCP 111, RFC 4181, September 2005.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, December 2002.
[RFC_CCCC]
Harrington, D., "SAMPLE Protocol Document", RFC CCCC,
December 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
12.2. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
Harrington Expires April 1, 2006 [Page 15]
Internet-Draft MIB Module Template September 2005
Author's Address
David Harrington (editor)
Effective Software Consulting
50 Harding Rd
Portsmouth, NH 03801
USA
Phone: +1 603 436 8634
EMail: dbharrington@comcast.net
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
Harrington Expires April 1, 2006 [Page 16]
Internet-Draft MIB Module Template September 2005
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Harrington Expires April 1, 2006 [Page 17]
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<?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 & 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-00.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 & 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(bis),
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="RFC_CCCC">"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 <ietfmibs@ops.ietf.org>"
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>
<!--
<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>
<!-- 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. -->
<reference anchor='RFC2629'>
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author initials='M.T.' surname='Rose' fullname='Marshall T. Rose'>
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country></postal>
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri></address></author>
<date year='1999' month='June' />
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t></abstract></front>
<seriesInfo name='RFC' value='2629' />
<format type='TXT' octets='48677' target='ftp://ftp.isi.edu/in-notes/rfc2629.txt' />
<format type='HTML' octets='58930' target='http://xml.resource.org/public/rfc/html/rfc2629.html' />
<format type='XML' octets='50797' target='http://xml.resource.org/public/rfc/xml/rfc2629.xml' />
</reference>
<reference anchor='RFC2863'>
<front>
<title>The Interfaces Group MIB</title>
<author initials='K.' surname='McCloghrie' fullname='K. McCloghrie'>
<organization /></author>
<author initials='F.' surname='Kastenholz' fullname='F. Kastenholz'>
<organization /></author>
<date year='2000' month='June' /></front>
<seriesInfo name='RFC' value='2863' />
<format type='TXT' octets='155014' target='ftp://ftp.isi.edu/in-notes/rfc2863.txt' />
</reference>
<reference anchor="RFC4181">
<front>
<title>Guidelines for Authors and Reviewers of MIB Documents</title>
<author initials="C." surname="Heard" fullname="C. Heard">
<organization />
</author>
<date year="2005" month="September" />
</front>
<seriesInfo name="BCP" value="111" />
<seriesInfo name="RFC" value="4181" />
<format type="TXT" octets="102521" target="ftp://ftp.isi.edu/in-notes/rfc4181.txt"; />
</reference>
<reference anchor="RFC3418">
<front>
<title>Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)</title>
<author initials="R." surname="Presuhn" fullname="R. Presuhn">
<organization />
</author>
<date year="2002" month="December" />
</front>
<seriesInfo name="STD" value="62" />
<seriesInfo name="RFC" value="3418" />
<format type="TXT" octets="49096" target="ftp://ftp.isi.edu/in-notes/rfc3418.txt"; />
</reference>
<reference anchor="RFC_CCCC">
<front>
<title>SAMPLE Protocol Document</title>
<author initials="D." surname="Harrington" fullname="David Harrington">
<organization />
</author>
<date year="2002" month="December" />
</front>
<seriesInfo name="RFC" value="CCCC" />
</reference>
<!-- 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. -->
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<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
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='14486' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5661' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor="RFC2578">
<front>
<title abbrev="SMIv2">Structure of Management Information Version 2 (SMIv2)</title>
<author initials="K." surname="McCloghrie" fullname="Keith McCloghrie" role="editor">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>
<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author><author initials="D." surname="Perkins" fullname="David Perkins" role="editor">
<organization>SNMPinfo</organization>
<address>
<postal>
<street>3763 Benton Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country>
</postal>
<phone>+1 408 221 8702</phone>
<email>dperkins@snmpinfo.com</email>
</address>
</author>
<author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder" role="editor">
<organization>TU Braunschweig</organization>
<address>
<postal>
<street>Bueltenweg 74/75</street>
<street>38106 Braunschweig</street>
<country>DE</country>
</postal>
<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>
<date year="1999" month="April" />
</front>
<seriesInfo name="STD" value="58" />
<seriesInfo name="RFC" value="2578" />
<format type="TXT" octets="89712" target="ftp://ftp.isi.edu/in-notes/rfc2578.txt"; />
</reference>
<reference anchor="RFC2579">
<front>
<title>Textual Conventions for SMIv2</title>
<author initials="K." surname="McCloghrie" fullname="Keith McCloghrie" role="editor">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>
<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>
<author initials="D." surname="Perkins" fullname="David Perkins" role="editor">
<organization>SNMPinfo</organization>
<address>
<postal>
<street>3763 Benton Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country>
</postal>
<phone>+1 408 221 8702</phone>
<email>dperkins@snmpinfo.com</email>
</address>
</author>
<author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder" role="editor">
<organization>TU Braunschweig</organization>
<address>
<postal>
<street>Bueltenweg 74/75</street>
<street>38106 Braunschweig</street>
<country>DE</country>
</postal>
<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>
<date year="1999" month="April" />
</front>
<seriesInfo name="STD" value="58" />
<seriesInfo name="RFC" value="2579" />
<format type="TXT" octets="59039" target="ftp://ftp.isi.edu/in-notes/rfc2579.txt"; />
</reference>
<reference anchor="RFC2580">
<front>
<title>Conformance Statements for SMIv2</title>
<author initials="K." surname="McCloghrie" fullname="Keith McCloghrie">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134-1706</code>
<country>US</country>
</postal>
<phone>+1 408 526 5260</phone>
<email>kzm@cisco.com</email>
</address>
</author>
<author initials="D." surname="Perkins" fullname="David Perkins">
<organization>SNMPinfo</organization>
<address>
<postal>
<street>3763 Benton Street</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95051</code>
<country>US</country>
</postal>
<phone>+1 408 221 8702</phone>
<email>dperkins@snmpinfo.com</email>
</address>
</author>
<author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder">
<organization>TU Braunschweig</organization>
<address>
<postal>
<street>Bueltenweg 74/75</street>
<city>Braunschweig</city>
<code>38106</code>
<country>DE</country>
</postal>
<phone>+49 531 3913283</phone>
<email>schoenw@ibr.cs.tu-bs.de</email>
</address>
</author>
<date year="1999" month="April" />
</front>
<seriesInfo name="STD" value="58" />
<seriesInfo name="RFC" value="2580" />
<format type="TXT" octets="54253" target="ftp://ftp.isi.edu/in-notes/rfc2580.txt"; />
</reference>
<!-- 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. -->
<reference anchor="RFC3410">
<front>
<title>Introduction and Applicability Statements for Internet-Standard Management Framework</title>
<author initials="J." surname="Case" fullname="J. Case">
<organization />
</author>
<author initials="R." surname="Mundy" fullname="R. Mundy">
<organization />
</author>
<author initials="D." surname="Partain" fullname="D. Partain">
<organization />
</author>
<author initials="B." surname="Stewart" fullname="B. Stewart">
<organization />
</author>
<date year="2002" month="December" />
</front>
<seriesInfo name="RFC" value="3410" />
<format type="TXT" octets="61461" target="ftp://ftp.isi.edu/in-notes/rfc3410.txt"; />
</reference>
<!-- include='./reference.RFC.3410.xml'? -->
<!-- to add a reference to an internet-draft, use the following approach -->
<!--
< include='reference.I-D.harrington-xml2rfc-mib-template'?>
-->
<!-- end of informative references that are required to support the boilerplate text. -->
</references>
</back>
</rfc>