[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Last call
Hi,
I'd like to start a two-week MIB Doctor Last Call on the MIB Template,
before I ask Bert to post it to the OPS Area web site.
I have included the XML2RFC template (which you should review for the
comments that don't get printed out, and the output file from running
the template through XML2RFC.
(Note that the template will require the "bleeding edge" version to
recognize the rfcedstyle directive. The production version and the web
services versions produce slightly different formatting in the
output.)
I just knew all you geeks would have nothing better to do during the
Christmas and New Year's weeks ;-)
David Harrington
dbharrington@comcast.net
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- xml2rfc offers an include feature described in the xml2rfc README file. That syntax, however, contradicts the DTD requirements to have <reference> elements within the <references> element, so an XML parser is likely to find your XML file invalid. It may be possible that xml2rfc will change their DTD so that the XML file remains valid when their style of include is used.
In the meantime therefore, we use an alternative valid-XML approach to includes, which unfortunately require that define your includes at the beginning of the file. Since the biggest benefit of includes is for references, this requires that your references be defined in ENTITY cluases here before being "included" and cited elsewhere in the file.
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc0768 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2578 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml'>
<!ENTITY rfc2579 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml'>
<!ENTITY rfc2580 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml'>
<!ENTITY rfc2629 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
<!ENTITY rfc2863 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml'>
<!ENTITY rfc3410 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml'>
<!ENTITY rfc3418 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml'>
<!ENTITY rfc4181 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4181.xml'>
]
>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="no"?>
<!-- ?rfc rfcedstyle="yes"? -->
<!--This template is for authors of IETF specifications containing MIB modules. This template can be used as a starting point to produce specifications that comply with the Operations & 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-01.txt" >
<!--
$Header$
place for source control header here, if desired
-->
<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 <xref target="RFC2629"></xref>,
http://xml.resource.org/public/rfc/html/rfc2629.html and "bis":
http://xml.resource.org/authoring/draft-mrose-writing-rfcs.html. Also see
http://xml.resource.org/authoring/README.html for 'rfc' option
strings.</t>
<t>You don't need to have any other tools than a 'notepad'
or your favourite editor to write xml2rfc drafts. You can use the web
interface at http://xml.resource.org for processing. The benefit of using
xml editors is mostly catching those missing tags which the processor will
warn you about, but you don't need to worry about the editors when getting
started.</t>
<t>This template is not meant to be a conclusive list of everything,
but summarize the often-needed basic features to get one started.</t>
<t>ATTN: please remove this Forward prior to publication.</t>
</note>
</front>
<middle>
<section title="Introduction">
<!-- It is good practice to echo the abstract in the Introduction, providing citations here. -->
<t>This memo defines a portion of the Management Information
Base (MIB) for use with network management protocols. In particular it defines objects
for managing the SAMPLE protocol, defined in <xref
target="RFC0768">"The SAMPLE Protocol"</xref> [ATTN: describe what functionality will be managed using this MIB module.]
</t>
</section>
<!-- This section MUST contain a verbatim copy of the latest approved
Internet-Standard Management Framework boilerplate, which is
available on-line at http://www.ops.ietf.org/mib-boilerplate.html. -->
<!-- The following boilerplates have been copied from the official boilerplate, and should not be modified unless the boilerplate text at http;//ops.ietf.org/ has changed.-->
<section title="The Internet-Standard Management Framework">
<t>
For a detailed overview of the documents that describe the
current Internet-Standard Management Framework, please refer
to section 7 of RFC 3410 <xref target="RFC3410"/>.
</t>
<t>
Managed objects are accessed via a virtual information store,
termed the Management Information Base or MIB. MIB objects
are generally accessed through the Simple Network Management
Protocol (SNMP). Objects in the MIB are defined using the
mechanisms defined in the Structure of Management Information
(SMI). This memo specifies a MIB module that is compliant to
the SMIv2, which is described in STD 58, RFC 2578 <xref
target="RFC2578"/>, STD 58, RFC 2579 <xref target="RFC2579"/>
and STD 58, RFC 2580 <xref target="RFC2580"/>.
</t>
</section>
<section title="Conventions" >
<!-- This boilerplate should be used if the following key words are used. -->
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL", when they appear in this
document, are to be interpreted as described in BCP 14, RFC
2119 <xref target="RFC2119"/>.
</t>
<!-- end conventions; -->
</section>
<!-- ********************************************* -->
<section title="Overview">
<!-- The narrative part MUST include an overview section that describes
the scope and field of application of the MIB modules defined by the
specification.
-->
<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">
<!-- The narrative part SHOULD include one or more
sections to briefly describe the structure of the MIB modules defined
in the specification. -->
<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. Objects 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">
<!-- ATTN: The narrative part MUST include a section that specifies
the relationship (if any) of the MIB modules contained in this document
to other standards, particularly to standards containing other MIB modules.
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 narrataive 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, 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.
-->
<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">
<!--ATTN This section is included as an example; If the MIB module is not an adjunct of the Interface MIB, then this section should be removed.-->
<t>The Interface MIB <xref target="RFC2863"/> requires that any MIB module which is an adjunct
of the Interface MIB clarify specific areas within the Interface MIB.
These areas were intentionally left vague in the Interface MIB to
avoid over constraining the MIB, thereby precluding management of
certain media-types.</t>
<t>Section 4 of <xref target="RFC2863"/> enumerates several areas which a
media-specific MIB must clarify. The implementor is referred to <xref target="RFC2863"/> in order to understand the general intent of these areas.</t>
</section>
<section title="MIB modules required for IMPORTS">
<!-- ATTN: Citations are not permitted within a MIB module, but any module mentioned in an IMPORTS clause or document mentioned in a REFERENCE clause is a Normative reference, and must be cited someplace within the narrative sections. If there are imported items in the MIB module, such as Textual Conventions, that are not already cited, they can be cited in text here. Since relationships to other MIB modules should be described in the narrative text, this section is typically used to cite modules from which Textual Conventions are imported. -->
<t> The following MIB module IMPORTS objects from SNMPv2-SMI <xref target="RFC2578"></xref>, SNMPv2-TC <xref target="RFC2579"></xref>, SNMPv2-CONF <xref target="RFC2580"></xref>, and IF-MIB <xref target="RFC2863"></xref> and also REFERENCEs document RFC0768 <xref target="RFC0768"></xref>
</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 0768 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 0768 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" >
<t>list the tables and objects and state why they are sensitive.</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" >
<t> list the tables and objects and state why they are sensitive.</t>
</list>
</t>
<!-- discuss what security the protocol used to carry the information should have. If Internet-drafts and RFCs do not contain the following three paragraphs, it will almost certainly require justification. -->
<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 <xref target="RFC3410"></xref>, 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>
<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>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 Randy Presuhn for the 'include' statement format.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Marshall Rose for developing the XML2RFC format. Pekka Savola developed an XML2RFC template, upon which the MIB module template is based.</t>
</section>
</middle>
<back>
<!-- References Section -->
<!-- Section 4.7f of [RFC2223bis] specifies the requirements for the
references sections. In particular, there MUST be separate lists of
normative and informative references, each in a separate section.
The style SHOULD follow that of recently published RFCs.
The standard MIB boilerplate available at
http://www.ops.ietf.org/mib-boilerplate.html includes lists of
normative and informative references that MUST appear in all IETF
specifications that contain MIB modules. If items from other MIB
modules appear in an IMPORTS statement in the Definitions section,
then the specifications containing those MIB modules MUST be included
in the list of normative references. When items are imported from an
IANA-maintained MIB module the corresponding normative reference
SHALL point to the on-line version of that MIB module. It is the
policy of the RFC Editor that all references must be cited in the
text; such citations MUST appear in the overview section where
documents containing imported definitions (other those already
mentioned in the MIB boilerplate) are required to be mentioned (cf.
Section 3.2).
In general, each normative reference SHOULD point to the most recent
version of the specification in question.
-->
<!-- references split to informative and normative -->
<references title="Normative References">
<!-- start of normative references that are required only to support this template, and which can be removed from the final document. -->
&rfc2629;
&rfc2863;
&rfc3418;
&rfc0768;
<!-- end of normative references that are required only to support this template; Remove from the final document. -->
<!-- start of normative references that are required to support the boilerplate text. -->
&rfc2119;
&rfc2578;
&rfc2579;
&rfc2580;
<!-- end of references that are required to support the boilerplate text. -->
<!-- ATTN: start of normative references samples. Replace with your own. -->
<!-- end of normative references samples. -->
</references>
<references title="Informative References">
<!-- start of informative references that are required to support the boilerplate text. -->
&rfc3410;
<!-- end of informative references that are required to support the boilerplate text. -->
</references>
<!--
<section anchor="appendix" title="Appendix A">
<t>You can add appendices just as regular sections, the only
difference is that they go under "back" element, and get letters instead of numbers</t>
</section>
-->
<section title="Changes from RFC BBBB (the previous RFC for this specification)">
<t>
The following changes have been made from RFC BBBB.
</t>
<t>
<list style="numbers">
<t> Translated the MIB definitions to use SMIv2. This includes
the introduction of conformance statements. ASN.1 type
definitions have been converted into textual-conventions
and several units clauses were added. </t>
<t>The sample999 group was added.</t>
<t> Permissible values for samplePriority have been clarified. </t>
<t> Interpretation of sampleLastChange has been
clarified. </t>
<t> Updated the introductionary boilerplate text, the security
considerations section and the references to comply with the
current IETF standards and guidelines. </t>
<t> Additions and clarifications in various description clauses. </t>
</list>
</t>
</section>
<section title="Open Issues">
<t>
This list of open issues should be cleared and removed before
this document hits the IESG.
</t>
<t>
<list style="numbers">
<t>
Contributor addresses need to be updated
</t>
<t>
The interaction of sample1 and sample999 behaviors needs to be clarified.
</t>
</list>
</t>
</section>
<!--
$Log$
place for source control log here
-->
</back>
</rfc>
Internet Engineering Task Force D. Harrington, Ed.
Internet-Draft Effective Software Consulting
Expires: June 22, 2006 December 19, 2005
A Template for XML2RFC MIB Module Documents
draft-harrington-xml2rfc-mib-template-01.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 June 22, 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 June 22, 2006 [Page 1]
Internet-Draft MIB Module Template December 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 [RFC2629],
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 June 22, 2006 [Page 2]
Internet-Draft MIB Module Template December 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
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Changes from RFC BBBB (the previous RFC for this
specification) . . . . . . . . . . . . . . . . . . . 15
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Harrington Expires June 22, 2006 [Page 3]
Internet-Draft MIB Module Template December 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" [RFC0768] [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 June 22, 2006 [Page 4]
Internet-Draft MIB Module Template December 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. Objects
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 June 22, 2006 [Page 5]
Internet-Draft MIB Module Template December 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
The Interface MIB [RFC2863] requires that any MIB module which is an
adjunct of the Interface MIB clarify specific areas within the
Interface MIB. These areas were intentionally left vague in the
Interface MIB to avoid over constraining the MIB, thereby precluding
management of certain media-types.
Section 4 of [RFC2863] enumerates several areas which a media-
specific MIB must clarify. The implementor is referred to [RFC2863]
in order to understand the general intent of these areas.
6.3. MIB modules required for IMPORTS
The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578],
SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], and IF-MIB [RFC2863] and
also REFERENCEs document RFC0768 [RFC0768]
7. Definitions
SAMPLE-MIB DEFINITIONS ::= BEGIN
-- ---------------------------------------------------------- --
-- MIB for SAMPLE devices
-- ---------------------------------------------------------- --
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Counter32, Integer32, TimeTicks, mib-2
Harrington Expires June 22, 2006 [Page 6]
Internet-Draft MIB Module Template December 2005
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)
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."
Harrington Expires June 22, 2006 [Page 7]
Internet-Draft MIB Module Template December 2005
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
Harrington Expires June 22, 2006 [Page 8]
Internet-Draft MIB Module Template December 2005
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 0768 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 0768 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
Harrington Expires June 22, 2006 [Page 9]
Internet-Draft MIB Module Template December 2005
"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 }
Harrington Expires June 22, 2006 [Page 10]
Internet-Draft MIB Module Template December 2005
-- ---------------------------------------------------------- --
-- 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
Harrington Expires June 22, 2006 [Page 11]
Internet-Draft MIB Module Template December 2005
"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
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 list the tables and objects and state why they are sensitive.
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 list the tables and objects and state why they are sensitive.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
Harrington Expires June 22, 2006 [Page 12]
Internet-Draft MIB Module Template December 2005
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
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 June 22, 2006 [Page 13]
Internet-Draft MIB Module Template December 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 Randy
Presuhn 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.
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.
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62,
RFC 3418, December 2002.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[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.
Harrington Expires June 22, 2006 [Page 14]
Internet-Draft MIB Module Template December 2005
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.
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 June 22, 2006 [Page 15]
Internet-Draft MIB Module Template December 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
Harrington Expires June 22, 2006 [Page 16]
Internet-Draft MIB Module Template December 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 June 22, 2006 [Page 17]
- Follow-Ups:
- Re: Last call
- From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>