[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last call
Hi,
I can give you a pretty printed version of the XML, using XMLSpy, but
the wordwrap feature is based in the size of the window rather than a
specified column width, and the subsequent indentation isn't as pretty
as I'd like to see.
Who said XML is human-friendly? ;-)
David Harrington
dbharrington@comcast.net
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]
> Sent: Thursday, December 22, 2005 10:33 AM
> To: David B Harrington
> Cc: 'MIB Doctors'
> Subject: Re: Last call
>
> On Mon, Dec 19, 2005 at 06:57:57PM -0500, David B Harrington wrote:
>
> > 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.
>
> My main observation is that the document currently mixes information
> concerning
>
> (a) how to use the xml2rfc format
> (b) how to structure a MIB document
> (c) sample text that must be rewritten/removed when you use
> the template
> (d) text intended to be copied verbatim
>
> and it is not always clear what is what. (a) is mostly captured in
XML
> comments, (b) is captured in the text produced but also in XML
> comment, while (c) and (d) are mostly text being produced on the
> output. I think it will help clarity if things are dealt with in a
> more consistent and easy to recognize way. (Otherwise we will for
sure
> see MIB modules which tell us something about sampl999 features ;-)
>
> My proposal would be to capture (a) in XML comments, (b) and (d)
> should be the output generated when you run xml2rfc and (c) should
> either be just XML comments or it should be output (pick one
option).
> In any case, I think (c) needs to be clearly marked.
>
> My second observation is that the plain .xml is rather hard to read,
> most likely because it was produced by a tool which does not care
much
> of producing human readable output (= nicely indented output with
text
> broken such that it fits on classic 80 column displays). I tried to
> run various XML formatters - they usually get the XML indentation
> right but do a poort job to align the text. Does anybody out there
> have a pointer to a good free tool to get this straight?
>
> My third observation is that the MIB module fragment should have
less
> syntax errors. In addition, I recommend to not use comments with
lines
> consisting of hyphens since many people do not understand the ASN.1
> rules for comments and might have interesting surprises when they
> add/remove hyphens or insert white space at interesting places. I
was
> also a bit confused why you have explicit GROUP clauses in the
> MODULE-COMPLIANCE statements that repeat that modules are mandatory.
>
> /js
>
> --
> Juergen Schoenwaelder International University Bremen
> <http://www.eecs.iu-bremen.de/> P.O. Box 750 561,
> 28725 Bremen, Germany
>
<?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: e:\\src\\master/IETFsources/draft-harrington-xml2rfc-mib-template.xml,v 1.4 2005/12/20 00:09:39 dbh Exp $
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"></date>
<!-- 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"></xref>.
</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"></xref>, STD 58, RFC 2579 <xref target="RFC2579"></xref>
and STD 58, RFC 2580 <xref target="RFC2580"></xref>.
</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"></xref>.
</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"></xref> and the 'interfaces' group of the
IF-MIB <xref target="RFC2863"></xref>.
</t>
<section title="Relationship to the SNMPv2-MIB">
<t>
The 'system' group in the SNMPv2-MIB <xref target="RFC3418"></xref> 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"></xref> 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"></xref> enumerates several areas which a
media-specific MIB must clarify. The implementor is referred to <xref target="RFC2863"></xref> 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: draft-harrington-xml2rfc-mib-template.xml,v $
Revision 1.4 2005/12/20 00:09:39 dbh
submitted to mreview for Last Call. Runs cleanly through Bill's validator, and the production and dev versions of xml2rfc. Also aubmitted the output file produced by the web service from this source file. Note that the rfcedstyle is disabled because the directive is only available in the "bleeding edge" version.
place for source control log here
-->
</back>
</rfc>
- References:
- Re: Last call
- From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>