[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
XML2RFC template for MIB modules
Hi,
I have enclosed a text document that is the output of my xml2rfc MIB
module template, so you can see roughly what will get generated, and
can comment on the layout, etc.
I have enclosed the XML template for writing MIB modules. It was used
to generate the text document. It is peppered with comments that do
not show up in the output document. Please review those comments as
well.
For those who do not yet have xml2rfc, you can use the web service,
available on that site. Just give it an XML file in the appropriate
format (like the one I have included) and it will generate text, HTML,
nroff, or other file types.
To install xml2rfc on your own system, the xml2rfc tool is available
from http://xml.resource.org/. It is a TCL-driven program, so you'll
also need TCL. The tool is based on RFC2629. The rfc2629.dtd file in
the distribution contains the DTD used to do the translations. The
README file link on the website and in the distribution explains all
the tags.
The distribution also contains xslt files and some templates for
non-MIB documents. I haven't used these much since I don't maintain a
website.
The xml2rfc website also contains citation libraries. It is a bit
painful writing the references in XML. The citation libraries can be
used online (cut and paste), or downloaded to your local system.
There is a mailing list where you can ask questions or request
enhancements.
I personally use the free XMLSpy editor home edition, which provides
checking for well-formed and valid XML.
Let me say that I have been doing the "final" editing of the Bridge
documents in nroff, and the editing of ISMS document in xml2rfc. What
a difference!!! You will quickly gain back the time it takes to learn
the xml2rfc tool in the time saved editing a document.
Comments welcome,
David Harrington
dbharrington@comcast.net
<?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"?>
<!--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>
<section title="Conventions" >
<!-- 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="Key Words">
<!-- 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>
</section>
<section title="Textual Conventions">
<t> Objects defined using Textual Conventions conventions are always encoded by means of the
rules that define their primitive type. Textual conventions are adopted merely for the convenience of
readers. </t>
<t >Generic and Common Textual Conventions can be found summarized at http://www.ops.ietf.org/mib-common-tcs.html </t>
</section>
<!-- end conventions; -->
</section>
<section title="Narrative Sections" >
<!-- 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 cument.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>
<section title="Design Principles">
<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>
<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">
<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>
</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.-->
<section title="Sensitive Modifiable Objects">
<!-- 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>
</section>
<section title="Sensitive Readable Objects">
<!--.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>
</section>
<section title="Protocol Security">
<!-- 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>
<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="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>
<!-- possibly a 'Contributors' 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. -->
<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="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="RFC_CCCC">
<front>
<title>
A SAMPLE Protocol version 2
</title>
<author role="editor" initials="D" surname="Harrington" fullname="David Harrington">
<organization></organization>
</author>
<date month="June" year="2004"/>
</front>
</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>
Key words for use in RFCs to Indicate Requirement Levels
</title>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997"/>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>
<reference anchor="RFC2578">
<front>
<title>Structure of Management Information Version 2 (SMIv2)</title>
<author initials="K." surname="McCloghrie"
fullname="Keith McCloghrie">
<organization abbrev="Cisco">
Cisco Systems, Inc.
</organization>
</author>
<author initials="D." surname="Perkins"
fullname="David Perkins">
<organization>
</organization>
</author>
<author initials="J." surname="Schoenwaelder"
fullname="Juergen Schoenwaelder">
<organization>
</organization>
</author>
<author initials="J." surname="Case"
fullname="Jeff Case">
<organization abbrev="SRI">
SNMP Research, Inc.
</organization>
</author>
<author initials="M." surname="Rose"
fullname="Marshall Rose">
<organization>
</organization>
</author>
<author initials="S." surname="Waldbusser"
fullname="Steve Waldbusser">
<organization>
retired
</organization>
</author>
<date month="April" year="1999" />
</front>
<seriesInfo name="RFC" value="2578" />
<seriesInfo name="STD" value="58" />
</reference>
<reference anchor="RFC2579">
<front>
<title>Textual Conventions for SMIv2</title>
<author initials="K." surname="McCloghrie"
fullname="Keith McCloghrie">
<organization abbrev="Cisco">
Cisco Systems, Inc.
</organization>
</author>
<author initials="D." surname="Perkins"
fullname="David Perkins">
<organization>
</organization>
</author>
<author initials="J." surname="Schoenwaelder"
fullname="Juergen Schoenwaelder">
<organization>
</organization>
</author>
<author initials="J." surname="Case"
fullname="Jeff Case">
<organization abbrev="SRI">
SNMP Research, Inc.
</organization>
</author>
<author initials="M." surname="Rose"
fullname="Marshall Rose">
<organization>
</organization>
</author>
<author initials="S." surname="Waldbusser"
fullname="Steve Waldbusser">
<organization>
retired
</organization>
</author>
<date month="April" year="1999" />
</front>
<seriesInfo name="RFC" value="2579" />
<seriesInfo name="STD" value="58" />
</reference>
<reference anchor="RFC2580">
<front>
<title>Conformance Statements for SMIv2</title>
<author initials="K." surname="McCloghrie"
fullname="Keith McCloghrie">
<organization abbrev="Cisco">
Cisco Systems, Inc.
</organization>
</author>
<author initials="D." surname="Perkins"
fullname="David Perkins">
<organization>
</organization>
</author>
<author initials="J." surname="Schoenwaelder"
fullname="Juergen Schoenwaelder">
<organization>
</organization>
</author>
<author initials="J." surname="Case"
fullname="Jeff Case">
<organization abbrev="SRI">
SNMP Research, Inc.
</organization>
</author>
<author initials="M." surname="Rose"
fullname="Marshall Rose">
<organization>
</organization>
</author>
<author initials="S." surname="Waldbusser"
fullname="Steve Waldbusser">
<organization>
retired
</organization>
</author>
<date month="April" year="1999" />
</front>
<seriesInfo name="RFC" value="2580" />
<seriesInfo name="STD" value="58" />
</reference>
<!-- end of references that are required to support the boilerplate text. -->
<!-- ATTN: start of normative references samples. Replace with your own. -->
<reference anchor="RFC2863">
<front>
<title>
The Interfaces Group MIB
</title>
<author initials="K." surname="McCloghrie" fullname="Keith McCloghrie">
<organization>Cisco Systems</organization>
</author>
<author initials="F." surname="Kastenholz" fullname="Frank Kastenholz">
<organization>FTP Software</organization>
</author>
<date month="June" year="2000"/>
</front>
<seriesInfo name="RFC" value="2863"/>
</reference>
<reference anchor="RFC3418">
<front>
<title>
Management Information Base (MIB) for the Simple Network
Management Protocol (SNMP)
</title>
<author initials="R." surname="Presuhn" fullname="Randy Presuhn">
<organization>BMC Software, Inc.</organization>
</author>
<date month="December" year="2002"/>
</front>
<seriesInfo name="STD" value="62"/>
<seriesInfo name="RFC" value="3418"/>
</reference>
<!-- 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="Jeff Case">
<organization abbrev="SRI">
SNMP Research, Inc.
</organization>
</author>
<author initials="R." surname="Mundy"
fullname="Russ Mundy">
<organization abbrev="Sparta">
Sparta
</organization>
</author>
<author initials="D." surname="Partain"
fullname="David Partain">
<organization>
Ericsson
</organization>
</author>
<author initials="B." surname="Stewart"
fullname="Bob Stewart">
<organization>
retired
</organization>
</author>
<date month="December" year="2002" />
</front>
<seriesInfo name="RFC" value="3410" />
</reference>
<!-- end of informative references that are required to support the boilerplate text. -->
</references>
<section anchor="appendix" title="Appendice 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>
Internet Engineering Task Force D. Harrington, Ed.
Internet-Draft Effective Software Consulting
Expires: March 31, 2006 September 27, 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 March 31, 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 March 31, 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 March 31, 2006 [Page 2]
Internet-Draft MIB Module Template September 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 The Internet-Standard Management Framework . . . . . . . . 4
2.2 Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Textual Conventions . . . . . . . . . . . . . . . . . . . 4
3. Narrative Sections . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Design Principles . . . . . . . . . . . . . . . . . . . . 5
3.3 Structure of the MIB Module . . . . . . . . . . . . . . . 6
3.3.1 The sample Group . . . . . . . . . . . . . . . . . . . 6
3.3.2 The sample999 Group . . . . . . . . . . . . . . . . . 6
3.3.3 The Notifications Group . . . . . . . . . . . . . . . 6
3.4 Relationship to Other MIB Modules . . . . . . . . . . . . 6
3.4.1 Relationship to the SNMPv2-MIB . . . . . . . . . . . . 7
3.4.2 Relationship to the IF-MIB . . . . . . . . . . . . . . 7
3.4.3 MIB modules required for Imports . . . . . . . . . . . 7
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.1 Sensitive Modifiable Objects . . . . . . . . . . . . . . . 13
5.2 Sensitive Readable Objects . . . . . . . . . . . . . . . . 13
5.3 Protocol Security . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1 Normative References . . . . . . . . . . . . . . . . . . . 15
8.2 Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
A. Appendice A . . . . . . . . . . . . . . . . . . . . . . . . . 16
B. Changes from RFC BBBB (the previous RFC for this
specification) . . . . . . . . . . . . . . . . . . . . . . . . 16
C. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 18
Harrington Expires March 31, 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. Conventions
2.1 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].
2.2 Key Words
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].
2.3 Textual Conventions
Objects defined using Textual Conventions conventions are always
encoded by means of the rules that define their primitive type.
Textual conventions are adopted merely for the convenience of
readers.
Generic and Common Textual Conventions can be found summarized at
http://www.ops.ietf.org/mib-common-tcs.html
3. Narrative Sections
3.1 Overview
This document provides analysis of application performance as
experienced by end-users.
Harrington Expires March 31, 2006 [Page 4]
Internet-Draft MIB Module Template September 2005
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.
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 ...
3.2 Design Principles
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:
1. Start with a small set of essential objects and add only as
objects are needed.
2. Require objects be essential for either fault or configuration
management.
3. Consider evidence of current use and/or utility.
4. Limit the total number of objects.
5. Exclude objects which are simply derivable from others in this or
other MIB modules.
6. Avoid causing critical sections to be heavily instrumented. The
guideline that was followed is one counter per critical section
Harrington Expires March 31, 2006 [Page 5]
Internet-Draft MIB Module Template September 2005
per layer.
7. 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.
3.3 Structure of the MIB Module
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.
3.3.1 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.
3.3.2 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.
3.3.3 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
utilizing the SAMPLE Protocol.
3.4 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].
Harrington Expires March 31, 2006 [Page 6]
Internet-Draft MIB Module Template September 2005
3.4.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.
3.4.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.
3.4.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]
4. 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
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)
Harrington Expires March 31, 2006 [Page 7]
Internet-Draft MIB Module Template September 2005
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 }
Harrington Expires March 31, 2006 [Page 8]
Internet-Draft MIB Module Template September 2005
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 }
Harrington Expires March 31, 2006 [Page 9]
Internet-Draft MIB Module Template September 2005
-- ---------------------------------------------------------- --
-- 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 }
Harrington Expires March 31, 2006 [Page 10]
Internet-Draft MIB Module Template September 2005
- ---------------------------------------------------------- --
-- 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
Harrington Expires March 31, 2006 [Page 11]
Internet-Draft MIB Module Template September 2005
-- ---------------------------------------------------------- --
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
Harrington Expires March 31, 2006 [Page 12]
Internet-Draft MIB Module Template September 2005
5. Security Considerations
5.1 Sensitive Modifiable Objects
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.
5.2 Sensitive Readable Objects
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
5.3 Protocol Security
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.
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
Harrington Expires March 31, 2006 [Page 13]
Internet-Draft MIB Module Template September 2005
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.
6. 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.
7. Acknowledgements
Thanks to Marshall Rose for developing the XML2RFC format. Pekka
Savola developed an XML2RFC template, upon which the MIB module
template is based.
8. References
Harrington Expires March 31, 2006 [Page 14]
Internet-Draft MIB Module Template September 2005
8.1 Normative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", BCP 111, RFC 4181, September 2005.
[RFC_CCCC]
Harrington, D., Ed., "A SAMPLE Protocol version 2",
June 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", RFC 2578, STD 58,
April 1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", RFC 2579, STD 58, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", RFC 2580, STD 58, April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, December 2002.
8.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 March 31, 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
Appendix A. Appendice A
You can add appendices just as regular sections, the only difference
is that they go under "back" element, and get letters instead of
numbers
Appendix B. 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 C. 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
Harrington Expires March 31, 2006 [Page 16]
Internet-Draft MIB Module Template September 2005
2. The interaction of sample1 and sample999 behaviors needs to be
clarified.
Harrington Expires March 31, 2006 [Page 17]
Internet-Draft MIB Module Template September 2005
Intellectual Property Statement
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
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Harrington Expires March 31, 2006 [Page 18]