INTERNET DRAFT                                       C. M. Heard, Editor
                                                              Consultant
                                                           February 2003


                Guidelines for MIB Authors and Reviewers

             <draft-ietf-ops-mib-review-guidelines-00.txt>


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This memo provides guidelines for authors and reviewers of IETF
   specifications containing MIB modules.














OPS Area                  Expires August 2003                   [Page 1]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


Table of Contents

   1 Introduction .................................................    3
   2 Terminology ..................................................    3
   3 General Documentation Guidelines .............................    4
   3.1 MIB Boilerplate Section ....................................    4
   3.2 Narrative Sections .........................................    4
   3.3 Definitions Section ........................................    5
   3.4 Intellectual Property Section ..............................    5
   3.5 References Sections ........................................    5
   3.6 Security Considerations Section ............................    5
   3.7 IANA Considerations Section ................................    6
   3.8 Copyright Notices ..........................................    7
   4 SMIv2 Usage Guidelines .......................................    8
   4.1 Module Names ...............................................    8
   4.2 Descriptors and Labels .....................................    8
   4.3 Naming Hierarchy ...........................................    9
   4.4 IMPORTS Statement ..........................................    9
   4.5 MODULE-IDENTITY Invocation .................................   10
   4.6 Textual Conventions and Object Definitions .................   11
   4.6.1 Usage of Data Types ......................................   11
   4.6.1.1 INTEGER, Integer32, Gauge32, and Unsigned32 ............   11
   4.6.1.2 Counter32 and Counter64 ................................   13
   4.6.1.3 CounterBasedGauge64 ....................................   14
   4.6.1.4 OCTET STRING ...........................................   14
   4.6.1.5 OBJECT IDENTIFIER ......................................   15
   4.6.1.6 The BITS Construct .....................................   15
   4.6.1.7 IpAddress ..............................................   16
   4.6.1.8 TimeTicks ..............................................   16
   4.6.1.9 TruthValue .............................................   16
   4.6.1.10 Other Data Types ......................................   16
   4.6.2 DESCRIPTION and REFERENCE Clauses ........................   17
   4.6.3 Conceptual Table Definitions .............................   17
   4.6.4 OID Values Assigned to Objects ...........................   19
   4.6.5 OID Length Limitations and Table Indexing ................   19
   4.7 Notification Definitions ...................................   20
   4.8 Compliance Statements ......................................   21
   4.9 Revisions to MIB Modules ...................................   23
    Appendix A:  MIB Review Checklist .............................   26
    Appendix B:  Using smilint to compile MIB modules .............   28
    Appendix C:  Using SMICng to compile MIB modules ..............   29
    Appendix D:  Commonly Used Textual Conventions ................   31
    Intellectual Property .........................................   33
    Normative References ..........................................   34
    Informative References ........................................   36
    Security Considerations .......................................   37
    Acknowledgments ...............................................   37
    Editor's Address ..............................................   37
    Full Copyright Statement ......................................   38


OPS Area                  Expires August 2003                   [Page 2]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


1.  Introduction

   Some time ago the IESG instituted a policy of requiring OPS area
   review of all IETF specifications containing MIB modules.  These
   reviews were established to ensure that such specifications follow
   established IETF documentation practices and that the MIB modules
   they contain meet certain generally accepted standards of quality,
   including (but not limited to) compliance with all syntactic and
   semantic requirements of SMIv2 (STD 58) [RFC2578] [RFC2579] [RFC2580]
   that are applicable to "standard" MIB modules.  The purpose of this
   memo is to document the guidelines that are followed in such reviews.

   Please note that the guidelines in this memo are not intended to
   alter requirements or prohibitions (in the sense of "MUST", "MUST
   NOT", "SHALL", or "SHALL NOT" as defined in RFC 2119 [RFC2119]) of
   existing BCPs or Internet Standards except where those requirements
   or prohibitions are ambiguous or contradictory.  In the exceptional
   cases where ambiguities or contradictions exist this memo documents
   the current generally accepted interpretation.  In certain instances
   the guidelines in this memo do alter recommendations (in the sense of
   "SHOULD", "SHOULD NOT", "RECOMMENDED", or "NOT RECOMMENDED" as
   defined in RFC 2119) of existing BCPs or Internet Standards.  This
   has been done where practical experience has shown that the published
   recommendations are suboptimal.  In addition, this memo provides
   guidelines for the selection of certain SMIv2 options (in the sense
   of "MAY" or "OPTIONAL" as defined in RFC 2119) in cases where there
   is a consensus on a preferred approach.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL", when used in the guidelines in this memo, are to be
   interpreted as described in RFC 2119 [RFC2119].

   The terms "MIB module" and "information module" are used
   interchangeably in this memo.  As used here, both terms refer to any
   of the three types of information modules defined in Section 3 of RFC
   2578 [RFC2578].












OPS Area                  Expires August 2003                   [Page 3]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


3.  General Documentation Guidelines

   In general, IETF specifications containing MIB modules MUST conform
   to the requirements for IETF RFCs documented in [RFC2223bis].
   Because the version under review will be an Internet Draft, the
   notices on the front page will comply with the requirements of
   http://www.ietf.org/ietf/1id-guidelines.txt and not with those of
   [RFC2223bis].  The rest of the requirements in [RFC2223bis] will,
   however, apply (see http://www.ietf.org/ID-nits.html for details).

   Section 4 of [RFC2223bis] lists the sections that may exist in an
   RFC.  The "body of memo" part of an RFC in general contains multiple
   sections, and in a MIB document MUST contain at least the following:

    o MIB boilerplate section

    o Narrative sections

    o Definitions section

    o Intellectual Property section

   Section-by-section guidelines follow.

3.1.  MIB Boilerplate 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

3.2.  Narrative Sections

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

   If the MIB modules defined by the specification are always
   implemented in conjunction with other MIB modules, then that fact
   MUST be noted in the overview section, as MUST any special
   interpretations of objects in other MIB modules.  For instance, so-
   called media-specific MIB 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



OPS Area                  Expires August 2003                   [Page 4]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   ifInvStackTable [RFC2864] to maintain information regarding
   configuration and multiplexing of interface sublayers must contain a
   description of the layering model.

3.3.  Definitions Section

   This section contains the MIB modules 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 for guidelines on SMIv2 usage.

3.4.  Intellectual Property Section

   Bullets (A) and (B) in Section 10.4 of RFC 2026 [RFC2026] specify
   that certain notices regarding intellectual or other property rights
   appear in all standards-track RFCs.  Verbatim copies of these so-
   called IPR notices MUST appear in each MIB document that is destined
   for the standards track.  If proprietary rights are known to be
   claimed with respect to the technology described in the document,
   then the notice in bullet (D) MUST also appear in the document.

3.5.  References Sections

   Section 4.8 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
   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 other MIB modules MUST be
   included in the list of normative references.

   In general, each normative reference SHOULD point to the most recent
   version of the specification in question.

3.6.  Security Considerations Section

   In order to comply with Section 4.9 of [RFC2223bis], each
   specification that defines one or more MIB modules MUST contain a
   section that discusses security considerations relevant to those MIB
   modules.  This section MUST be patterned after the latest approved
   template available at http://www.ops.ietf.org/mib-security.html.  In



OPS Area                  Expires August 2003                   [Page 5]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   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 MUST be explicitly
   listed by name and the reasons for the special sensitivity MUST be
   explained.

3.7.  IANA Considerations Section

   In order to comply with Section 4.10 of [RFC2223bis], each
   specification that defines a name space of assigned numbers MUST
   include an IANA Considerations section conforming to the guidelines
   set forth in [RFC2434] specifying how that name space is to be
   administered.

   Name spaces defined by MIB documents generally consist of the range
   of values for some type (usually an enumerated INTEGER) defined by a
   TEXTUAL-CONVENTION (TC) or of a set of administratively-defined
   OBJECT IDENTIFIER (OID) values.  In each case the definitions are
   housed in stand-alone MIB modules that are maintained by IANA.  These
   IANA-maintained MIB modules are kept separate from the MIB modules
   defined in standards-track specifications so that new assignments can
   be made without having to republish a standards-track RFC.  Examples
   of IANA-maintained MIB modules include the IANAifType-MIB
   (http://www.iana.org/assignments/ianaiftype-mib), which defines a
   name space used by the IF-MIB [RFC2863], and the IANA-RTPROTO-MIB
   (http://www.iana.org/assignments/ianaiprouteprotocol-mib), which
   defined a name space used by the IPMROUTE-STD-MIB [RFC2932].

   The current practice for such cases is to include a detailed IANA
   Considerations section complying with [RFC2434] in the DESCRIPTION
   clause of the MODULE-IDENTITY invocation in each IANA-maintained MIB
   module and for the IANA Considerations section of the MIB document
   that defines the name space to refer to the URLs for the relevant
   modules.  See RFC 2932 [RFC2932] for an example.  This creates a
   chicken-and-egg problem for MIB documents that have not yet been
   published as RFCs because the relevant IANA-maintained MIB modules
   will not yet exist.  The accepted way out of this dilemma is to
   include the initial content of the proposed IANA-maintained MIB
   modules in appendices of the Internet Draft with a note to the RFC
   Editor that those appendices are to be removed upon publication, when
   the IANA-maintained modules go on-line.

   Reviewers of draft MIB documents to which these considerations apply
   MUST check that the IANA Considerations section proposed for
   publication in the RFC is present and contains pointers to the
   appropriate IANA-maintained MIB modules.  Reviewers of Internet
   Drafts that contain the proposed initial content of IANA-maintained



OPS Area                  Expires August 2003                   [Page 6]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   MIB modules MUST also verify that the DESCRIPTION clauses of the
   MODULE-IDENTITY invocations contain an IANA Considerations section
   compliant with the guidelines in [RFC2434].

   Note that an IANA Considerations section is NOT required if the only
   IANA action needed is the assignment of the object identifier for the
   MIB module's MODULE-IDENTITY value.  A note in the form of an ASN.1
   comment requesting such an assignment is sufficient for this;  see
   Section 4.5 for an example.

3.8.  Copyright Notices

   IETF MIB documents MUST contain the copyright notices specified in
   Section 4.3 of RFC 2223bis [RFC2223bis] and Section 10.4 Bullet (C)
   of RFC 2026 [RFC2026].  Authors and reviewers MUST check make sure
   that the correct year is inserted into these notices.  In addition,
   the DESCRIPTION clause of the MODULE-IDENTITY invocation of each MIB
   module that will appear in the published RFC must contain a pointer
   to the copyright notices in the RFC.  A template suitable for
   inclusion in an Internet Draft is as follows:

          DESCRIPTION
            " [ ... ]

            Copyright (C) The Internet Society (date).  This version
            of this MIB module is part of RFC yyyy;  see the RFC
            itself for full legal notices."
   -- RFC Ed.: replace yyyy with actual RFC number & remove this note

   where the current year is inserted in place of the word "date".





















OPS Area                  Expires August 2003                   [Page 7]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


4.  SMIv2 Usage Guidelines

   In general, MIB modules in IETF standards-track specifications MUST
   comply with all syntactic and semantic requirements of SMIv2
   [RFC2578] [RFC2579] [RFC2580] that apply to "standard" MIB modules
   and except as noted below SHOULD comply with SMIv2 recommendations.
   The guidelines in this section are intended to supplement the SMIv2
   documents in the following ways:

    o to document the current generally accepted interpretation when
      those documents contain ambiguities or contradictions;

    o to update recommendations in those documents that have been shown
      by practical experience to be out-of-date or otherwise suboptimal;

    o to provide guidance in selection of SMIv2 options in cases where
      there is a consensus on a preferred approach.

4.1.  Module Names

   RFC 2578 Section 3 specifies the rules for module names.  Note in
   particular that names of "standard" modules MUST be unique, MUST
   follow the syntax rules in RFC 2578 Section 3, and MUST NOT be
   changed when a MIB module is revised (see also RFC 2578 Section 10).

   It is strongly RECOMMENDED that module names be mnemonic.

4.2.  Descriptors and Labels

   RFC 2578 Sections 3.1, 7.1.1, and 7.1.4 and RFC 2579 Section 3
   recommend that descriptors associated with macro invocations and
   labels associated with enumerated INTEGER and BITS values be no
   longer than 32 characters, but require that they be no longer than 64
   characters.

   Restricting descriptors and labels to 32 characters often conflicts
   with the recommendation that they be mnemonic and (for descriptors)
   with the requirement that they be unique (see RFC 2578 Section 3.1
   and RFC 2579 Section 3).  The consensus of the current pool of OPS
   Area MIB reviewers is that the SMIv2 recommendation to limit
   descriptors and labels to 32 characters SHOULD be set aside in favor
   of promoting clarity and uniqueness and that automated tools such as
   MIB compilers SHOULD NOT by default generate warnings for violating
   that recommendation.

   Note that violations of the 64 character limit MUST NOT be ignored;
   they MUST be treated as errors.




OPS Area                  Expires August 2003                   [Page 8]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


4.3.  Naming Hierarchy

   RFC 2578 Section 4 describes the object identifier subtrees that are
   maintained by IANA and specifies the usages for those subtrees.  In
   particular, the mgmt subtree { iso 3 6 1 2 } is used to identify IETF
   "standard" objects, while the experimental subtree { iso 3 6 1 3 } is
   used to identify objects that are under development in the IETF.  It
   is REQUIRED that objects be moved from the experimental subtree to
   the mgmt subtree when a MIB module enters the IETF standards track.

   Experience has shown that it is impractical to move objects from one
   subtree to another once those objects have seen large-scale use in an
   operational environment.  Hence any object that is targeted for
   deployment in an operational environment MUST NOT be registered under
   the experimental subtree, irrespective of the standardization status
   of that object.  The experimental subtree should be used only for
   objects that are intended for limited experimental deployment.  Such
   objects typically are defined in Experimental RFCs.

   Note:  the term "object", as used here and in RFC 2578 Section 4, is
   to be broadly interpreted as any construct that results in an OBJECT
   IDENTIFIER registration.  The list of such constructs is specified in
   RFC 2578 Section 3.6.

4.4.  IMPORTS Statement

   RFC 2578 Section 3.2 specifies which symbols must be imported and
   also lists certain pre-defined symbols that must not be imported.

   The general requirement is that if an external symbol other than a
   predefined ASN.1 type or the BITS construct is used, then it MUST be
   mentioned in the module's IMPORTS statement.  The words "external
   object" in the first paragraph of that section may give the
   impression that such symbols are limited to those that refer to
   object definitions, but that is not the case, as subsequent
   paragraphs should make clear.

   Note that exemptions to this general requirement are granted by RFC
   2580 Sections 5.4.3 and 6.5.2 for descriptors of objects appearing in
   the OBJECT clause of a MODULE-COMPLIANCE statement or in the
   VARIATION clause of an AGENT-CAPABILITIES statement.  Some MIB
   compilers also grant exemptions to descriptors of notifications
   appearing in a VARIATION clause and to descriptors of object groups
   and notification groups referenced by a MANDATORY-GROUPS clause, a
   GROUP clause, or an INCLUDES clause, although RFC 2580 (through
   apparent oversight) does not mention those cases.  The exemptions are
   sometimes seen as unhelpful because they make IMPORTS rules more
   complicated and inter-module dependencies less obvious than they



OPS Area                  Expires August 2003                   [Page 9]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   otherwise would be.  External symbols referenced by compliance
   statements and capabilities statements MAY therefore be listed in the
   IMPORTS statement;  if this is done, it SHOULD be done consistently.

   Finally, even though it is not forbidden by the SMI, it is considered
   poor style to import symbols that are not used, and "standard" MIB
   modules SHOULD NOT do so.

4.5.  MODULE-IDENTITY Invocation

   RFC 2578 Section 3 requires that all SMIv2 MIB modules start with
   exactly one invocation of the MODULE-IDENTITY macro.  This invocation
   MUST appear immediately after the IMPORTS statement.

   RFC 2578 Section 5 describes how the various clauses are used.  The
   following additional guidelines apply to all MIB modules over which
   the IETF has change control:

   - If the module was developed by an IETF working group, then the
     ORGANIZATION clause MUST provide the full name of the working
     group, and the CONTACT-INFO clause MUST include working group
     mailing list information.  The CONTACT-INFO clause SHOULD also
     provide a pointer to the working groups's web page.

   - A REVISION clause MUST be present for each revision of the MIB
     module, and the UTC time of the most recent REVISION clause MUST
     match that of the LAST-UPDATED clause.  The DESCRIPTION clause
     associated with each revision MUST state in which RFC that revision
     appeared and SHOULD provide a list of all significant changes.
     When a MIB module is revised UTC times in all REVISION clauses
     SHOULD be updated to use four-digit year notation.

   - The value assigned to the MODULE-IDENTITY descriptor MUST be unique
     and SHOULD reside under the mgmt subtree [RFC2578].  Most often it
     will be an IANA-assigned value directly under mib-2 [RFC2578],
     although for media-specific MIB modules that extend the IF-MIB
     [RFC2863] it is customary to use an IANA-assigned value under
     transmission [RFC2578].  It is also acceptable for a working group
     to make its own assignments from a subtree delegated to it by IANA,
     provided that adequate controls are in place to ensure that such
     assignments are unique.

   While a MIB module is under development, the RFC number in which it
   will eventually be published is usually unknown and must be filled in
   by the RFC Editor prior to publication.  An appropriate form for the
   REVISION clause applying to a version under development would be
   something along the following lines:




OPS Area                  Expires August 2003                  [Page 10]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


          REVISION    "200212132358Z"  -- December 13, 2002
          DESCRIPTION "Initial version, published as RFC yyyy."
   -- RFC Ed.: replace yyyy with actual RFC number & remove this note

   Note that after RFC publication a REVISION clause is present only for
   published versions of a MIB module and not for interim versions that
   existed only as Internet Drafts.  Thus, a draft version of a MIB
   module MUST contain just one new REVISION clause that covers all
   changes since the last published version (if any).

   When the initial version of a MIB module is under development, the
   value assigned to the MODULE-IDENTITY descriptor will be unknown if
   an IANA-assigned value is used, because the assignment is made just
   prior to publication as an RFC.  The accepted form for the MODULE-
   IDENTITY statement in draft versions of such a module is something
   along the following lines:

      <descriptor> MODULE-IDENTITY

          [ ... ]

          ::= { <subtree> XXX }
   -- RFC Ed.: replace XXX with IANA-assigned number & remove this note

   where <descriptor> is whatever descriptor has been selected for the
   module and <subtree> is the subtree under which the module is to be
   registered (e.g., mib-2 or transmission).  Note that XXX must be
   temporarily replaced by a number in order for the module to compile.

4.6.  Textual Conventions and Object Definitions

4.6.1.  Usage of Data Types

4.6.1.1.  INTEGER, Integer32, Gauge32, and Unsigned32

   The 32-bit integer data types INTEGER, Integer32, Gauge32, and
   Unsigned32 are described in RFC 2578 Section 2 and further elaborated
   in RFC 2578 Sections 7.1.1, 7.1.7, and 7.1.11.  The following
   guidelines apply when selecting one of these data types for an object
   definition or a textual convention:

   - For integer-valued enumerations:

     - INTEGER is REQUIRED;
     - Integer32, Unsigned32, and Gauge32 MUST NOT be used.

   Note that RFC 2578 recommends (but does not require) that integer-
   valued enumerations start at 1 and be numbered contiguously.  This



OPS Area                  Expires August 2003                  [Page 11]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   recommendation SHOULD be followed unless there is a valid reason to
   do otherwise, e.g., to match values of external data or to indicate
   special cases, and any such special-case usage SHOULD be clearly
   documented.  For an example see the InetAddressType TC [RFC3291].

   - If the value range is between -2147483648..2147483647 (inclusive)
     and negative values are possible, then:

     - Integer32 is RECOMMENDED;
     - INTEGER is acceptable;
     - Unsigned32 and Gauge32 MUST NOT be used.

   - If the value range is between 0..4294967295 (inclusive) and the
     value of the information being modelled may increase above the
     maximum value or decrease below the minimum value, then:

     - Gauge32 is RECOMMENDED;
     - Unsigned32 is acceptable;
     - INTEGER and Integer32 MUST NOT be used if
       values greater than 2147483647 are possible.

   - If the value range is between 0..4294967295 (inclusive), and values
     greater than 2147483647 are possible, and the value of the
     information being modelled does not increase above the maximum
     value nor decrease below the minimum value, then:

     - Unsigned32 is RECOMMENDED;
     - Gauge32 is acceptable;
     - INTEGER and Integer32 MUST NOT be used.

   - If the value range is between 0..2147483647 (inclusive), and the
     value of the information being modelled does not increase above the
     maximum value nor decrease below the minimum value, then:

     - Unsigned32 is RECOMMENDED;
     - INTEGER, Integer32, and Gauge32 are acceptable.

   - For integer-valued objects that appear in an INDEX clause or for
     integer-valued TCs that are to be used in an index column:

     - Unsigned32 with a range that excludes zero is RECOMMENDED for
       most index objects.  It is acceptable to include zero in the
       range when it is semantically significant or when it is used as
       the index value for a unique row with special properties.   Such
       usage SHOULD be clearly documented in the DESCRIPTION clause.

     - Integer32 or INTEGER with a non-negative range is acceptable.
       Again, zero SHOULD be excluded from the range except when it is



OPS Area                  Expires August 2003                  [Page 12]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


       semantically significant or when it is used as the index value
       for a unique row with special properties, and in such cases the
       usage SHOULD be clearly documented in the DESCRIPTION clause.

     - Use of Gauge32 is appropriate for index objects that have gauge
       semantics.

   The guidelines above combine both the usage rules for integer data
   types and the INDEX rules in RFC 2578 Section 7.7 up to and including
   bullet (1) plus the next-to-last paragraph on page 28.

   Sometimes it will be necessary for external variables to represent
   values of an index object -- e.g., ifIndex [RFC2863].  In such cases
   authors of the module containing that object SHOULD consider defining
   TCs such as InterfaceIndex and/or InterfaceIndexOrZero [RFC2863].

   Note that INTEGER is a pre-defined ASN.1 type and MUST NOT be present
   in a module's IMPORTS statement, whereas Integer32, Gauge32, and
   Unsigned32 are defined by SNMPv2-SMI and MUST be imported from that
   module if used.

4.6.1.2.  Counter32 and Counter64

   Counter32 and Counter64 have special semantics as described in RFC
   2578 Sections 7.1.6 and 7.1.10 respectively.  Object definitions MUST
   (and textual conventions SHOULD) respect these semantics.  That
   means:

   - It is OK to use Counter32/64 for counters that can reset themselves
     on unusual/irregular events (e.g., counters maintained on a line
     card may be reset when the line card is reset), and it is not
     illegal if their value after the reset happens to be zero (i.e., it
     does not have to be non-zero).  So, "counters that can reset to
     zero" is not automatically wrong for Counter32/64.  However, if it
     is possible for such resets to occur, then a discontinuity
     indicator object SHOULD be provided to indicate when the last such
     reset occurred.

   - It is NOT OK to put in the DESCRIPTION clause of a Counter32/64
     that there is a requirement that on a discontinuity the counter
     MUST reset to zero.

   - It is NOT OK to put in the DESCRIPTION clause of a Counter32/64
     that there is a requirement that it MUST reset at any specific
     time/event (e.g., midnight).

   - It is NOT OK for one manager to request the  agent to reset the
     value of counter(s) to zero, and Counter32/64 is the wrong syntax



OPS Area                  Expires August 2003                  [Page 13]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


     for "counters" which regularly reset themselves to zero.  For the
     latter it is better to define or use textual conventions such as
     those in RFC 2493 [RFC2493].

   There also exist closely-related textual conventions
   ZeroBasedCounter32 and ZeroBasedCounter64 defined in RMON2-MIB
   [RFC2021] and HCNUM-TC [RFC2856], respectively.

   The only difference between ZeroBasedCounter32/64 TCs and
   Counter32/64 is their starting value;  at time=X, where X is their
   minimum-wrap-time after they were created, the behaviour of
   ZeroBasedCounter32/64 becomes exactly the same as Counter32/64.
   Thus, the preceeding paragraphs/rules apply not only to Counter32/64,
   but also to ZeroBasedCounter32/64 TCs.

4.6.1.3.  CounterBasedGauge64

   SMIv2 unfortunately does not provide 64-bit integer base types.  In
   order to make up for this omission, the CounterBasedGauge64 textual
   convention is defined in HCNUM-TC [RFC2856].  This TC uses Counter64
   as a base type, but discards the special counter semantics, which is
   allowed under the generally accepted interpretation of RFC 2579
   Section 3.3.  It does inherit all the syntactic restrictions of that
   type, which means that it MUST NOT be subtyped and that objects
   defined with it MUST NOT appear in an INDEX clause, MUST NOT have a
   DEFVAL clause, and MUST have a MAX-ACCESS of read-only or
   accessible-for-notify.

   This TC SHOULD be used for object definitions that require a 64-bit
   unsigned data type with gauge semantics.  If a 64-bit unsigned data
   type with different semantics is needed, then a different TC based on
   Counter64 MUST be used, since one TC cannot refine another (cf. RFC
   2579 Section 3.5).

4.6.1.4.  OCTET STRING

   The OCTET STRING type is described in RFC 2578 Section 7.1.2.  It
   represents arbitrary binary or textual data whose length is between 0
   and 65535 octets inclusive.  Objects and TCs whose SYNTAX is of this
   type SHOULD have a size constraint when the actual bounds are more
   restrictive than the SMI-imposed limits.  This is particularly true
   for index objects.  Note, however, that size constraints SHOULD NOT
   be imposed arbitrarily, as the SMI does not permit them to be changed
   afterward.

   There exist a number of standard TCs that cater to some of the more
   common requirements for specialized OCTET STRING types.  In
   particular, SNMPv2-TC [RFC2579] contains the DisplayString,



OPS Area                  Expires August 2003                  [Page 14]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   PhysAddress, MacAddress, and DateAndTime TCs, and the SNMP-
   FRAMEWORK-MIB [RFC3411] contains the SnmpAdminString TC.  When a
   standard TC provides the desired semantics, it SHOULD be used in an
   object's SYNTAX clause instead of OCTET STRING or an equivalent
   locally-defined TC.

   Note that OCTET STRING is a pre-defined ASN.1 type and MUST NOT be
   present in a module's IMPORTS statement.

4.6.1.5.  OBJECT IDENTIFIER

   The OBJECT IDENTIFIER type is described in RFC 2578 Section 7.1.3.
   Its instances represent administratively assigned names.  Note that
   both the SMI and the SNMP protocol limit instances of this type to
   128 sub-identifiers and require that each sub-identifier be within
   the range 0 to 4294967295 inclusive.  Sub-typing is not allowed.

   The purpose of OBJECT IDENTIFIER values is to provide authoritative
   identification either for some type of item or for a specific
   instance of some type of item.  Among the items that can be
   identified in this way are definitions in MIB modules created via the
   MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
   OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE, and AGENT-
   CAPABILITIES constructs, instances of objects defined in MIB modules,
   protocols, languages, specifications, interface types, hardware, and
   software.  For some of these uses other possibilities exist, e.g.,
   OCTET STRING or enumerated INTEGER values.  The OBJECT IDENTIFIER
   type SHOULD be used instead of the alternatives when the set of
   identification values needs to be independently extensible without
   the need for a registry to provide centralized coordination.

   There exist a number of standard TCs that cater to some of the more
   common requirements for specialized OBJECT IDENTIFIER types.  In
   particular, SNMPv2-TC [RFC2579] contains the AutonomousType,
   VariablePointer, and RowPointerTCs.  When a standard TC provides the
   desired semantics, it SHOULD be used in an object's SYNTAX clause
   instead of OBJECT IDENTIFIER or an equivalent locally-defined TC.

   Note that OBJECT IDENTIFIER is a pre-defined ASN.1 type and MUST NOT
   be present in a module's IMPORTS statement.

4.6.1.6.  The BITS Construct

   The BITS construct is described in RFC 2578 Section 7.1.4.  It
   represents an enumeration of named bits.  The bit positions in a TC
   or object definition whose SYNTAX is of this type MUST start at 0 and
   MUST be contiguous.




OPS Area                  Expires August 2003                  [Page 15]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   Note that the BITS construct is defined by the macros that use it and
   therefore MUST NOT be present in a module's IMPORTS statement.

4.6.1.7.  IpAddress

   The IpAddress type described in RFC 2578 Section 7.1.5 SHOULD NOT be
   used in new MIB modules.  The InetAddress/InetAddressType textual
   conventions [RFC3291] SHOULD be used instead.

4.6.1.8.  TimeTicks

   The TimeTicks type is described in RFC 2578 Section 7.1.8.  It
   represents the time in hundredths of a second between two epochs,
   reduced modulo 2^32.  It MUST NOT be sub-typed, and the DESCRIPTION
   clause of any object or TC whose SYNTAX is of this type MUST identify
   the reference epochs.

   The TimeTicks type SHOULD NOT be used directly in definitions of
   objects that are snapshots of sysUpTime [RFC3418].  The TimeStamp TC
   [RFC2579] already conveys the desired semantics and SHOULD be used
   instead.

4.6.1.9.  TruthValue

   The TruthValue TC is defined in SNMPv2-TC [RFC2579].  It is an
   enumerated INTEGER type that assumes the values true(1) and false(2).

   This TC SHOULD be used in the SYNTAX clause of object definitions
   that require a Boolean type.  MIB modules SHOULD NOT use enumerated
   INTEGER types or define TCs that duplicate its semantics.

4.6.1.10.  Other Data Types

   There exist a number of standard TCs that cater to some of the more
   common requirements for specialized data types.  Some have been
   mentioned above, and Appendix D contains a partial list that includes
   those plus some others that are a bit more specialized.  Note that
   there exist many standard TCs that are not mentioned there;  that
   list can be expected to to grow as additional TCs are developed.

   Whenever a standard TC already conveys the desired semantics, it
   SHOULD be used in an object definition instead of the corresponding
   base type or a locally-defined TC.  This is especially true of the
   TCs defined in SNMPv2-TC [RFC2579] and SNMP-FRAMEWORK-MIB [RFC3411]
   because they are Internet Standards, and so modules that refer to
   them will not suffer delay in advancement on the standards track on
   account of such references.




OPS Area                  Expires August 2003                  [Page 16]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


4.6.2.  DESCRIPTION and REFERENCE Clauses

   It is hard to overemphasize the importance of an accurate and
   unambiguous DESCRIPTION clause for all objects and TCs.  The
   DESCRIPTION clause contains the instructions that implementors will
   use to implement an object, and if they are inadequate or ambiguous,
   then implementation quality will suffer.  Probably the single most
   important job of a MIB reviewer is to ensure that DESCRIPTION clauses
   are sufficiently clear and unambiguous to allow interoperable
   implementations to be created.

   A very common problem is to see an object definition for, say,
   "Number of poofpoofs" with no indication what a 'poofpoof' is.  In
   such cases it is strongly RECOMMENDED that there either be at least a
   minimal explanation or else a REFERENCE clause to point to the
   definition of a 'poofpoof'.

4.6.3.  Conceptual Table Definitions

   RFC 2578 Sections 7.1.12 and 7.1.12.1 specify the rules for defining
   conceptual tables, and RFC 2578 Sections 7.7, 7.8, and 7.8.1 specify
   conceptual table indexing rules.  The following guidelines apply to
   such definitions:

   - For conceptual rows:

     - If the row is an extension of a row in some other table, then an
       AUGMENTS clause MUST be used if the relationship is one-to-one,
       and an INDEX clause MUST be used if the relationship is sparse.
       In the latter case the INDEX clause SHOULD be identical to that
       of the original table.

     - If the row is an element of an expansion table -- that is, if
       multiple row instances correspond to a single row instance in
       some other table -- then an INDEX clause MUST be used, and the
       first-mentioned elements SHOULD be the indices of that other
       table, listed in the same order.

     - If objects external to the row are present in the INDEX clause,
       then the conceptual row's DESCRIPTION clause MUST specify how
       those objects are used in identifying instances of its columnar
       objects, and in particular MUST specify for which values of those
       index objects the conceptual row may exist.

   - If dynamic row creation and/or deletion by management applications
     is supported, then:





OPS Area                  Expires August 2003                  [Page 17]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


     - There MUST be one columnar object with a SYNTAX value of
       RowStatus [RFC2579] and a MAX-ACCESS value of read-create.  This
       object is called the status column for the conceptual row.  All
       other columnar objects MUST have a MAX-ACCESS value of read-
       create, read-only, accessible-for-notify, or not-accessible;  a
       MAX-ACCESS value of read-write is not allowed.

     - There either MUST be one columnar object with a SYNTAX value of
       StorageType [RFC2579] and a MAX-ACCESS value of read-create, or
       else the row object DESCRIPTION clause MUST specify what happens
       to dynamically-created rows after an agent restart.

     - If the agent itself may also create and/or delete rows, then the
       conditions under which this can occur MUST be clearly documented
       in the row object DESCRIPTION clause.

   - For conceptual rows that include a status column:

     - The DESCRIPTION clause of the status column MUST specify which
       columnar objects (if any) have to be set to valid values before
       the row can be activated.  If any objects in cascading tables
       have to be populated with related data before the row can be
       activated, then this MUST also be specified.

     - The DESCRIPTION clause of the status column MUST specify whether
       or not it is possible to modify other columns in the same
       conceptual row when the status value is active(1).  Note that in
       many cases it will be possible to modify some writeable columns
       when the row is active but not others.  In such cases the
       DESCRIPTION clause for each writeable column SHOULD state whether
       or not that column can be modified when the row is active, and
       the DESCRIPTION clause for the status column SHOULD state that
       modifiability of other columns when the status value is active(1)
       is specified in the DESCRIPTION clauses for those columns (rather
       than listing the modifiable columns individually).

   - For conceptual rows that include a StorageType column:

     - The DESCRIPTION clause of the StorageType column MUST specify
       which read-write or read-create columnar objects in permanent(4)
       rows an agent must, at a minimum, allow to be writable.

   Complete requirements for the RowStatus and StorageType TCs are can
   be found in RFC 2579, in the DESCRIPTION clauses for those TCs.







OPS Area                  Expires August 2003                  [Page 18]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


4.6.4.  OID Values Assigned to Objects

   RFC 2578 Section 7.10 specifies the rules for assigning OBJECT
   IDENFIFIER (OID) values to OBJECT-TYPE definitions.  In particular:

   - A conceptual table MUST have exactly one subordinate object, which
     is a conceptual row.  The OID assigned to the conceptual row MUST
     be derived by appending a sub-identifier of "1" to the OID assigned
     to the conceptual table.

   - A conceptual row has as many subordinate objects as there are
     columns in the row;  there MUST be at least one.  The OID assigned
     to each columnar object MUST be derived by appending a non-zero
     sub-identifier, unique within the row, to the OID assigned to the
     conceptual row.

   - A columnar or scalar object MUST NOT have any subordinate objects.

   - The last sub-identifier of an OID assigned to any object (be it
     table, row, column, or scalar) MUST NOT be equal to zero.  Note
     that sub-identifiers of intermediate nodes MAY be equal to zero.

   - The OID assigned to an object definition MUST NOT also be assigned
     to another definition that results in OID registration.  RFC 2578
     Section 3.6 lists the constructs that create OID registrations.

4.6.5.  OID Length Limitations and Table Indexing

   As specified in RFC 2578 Section 3.5, all OIDs are limited to 128
   sub-identifiers.  While this is not likely to cause problems with
   administrative assignments, it does place some limitations on table
   indexing.  That is true because the length limitation also applies to
   OIDs for object instances, and these consist of the concatenation of
   the "base" OID assigned in the object definition plus the index
   components.  When a table has multiple indices of types such as OCTET
   STRING or OBJECT IDENTIFIER that resolve to multiple sub-identifiers,
   then the 128 OID limitation can be quickly reached.

   Despite its inconvenience, the 128 sub-identifier limit is not
   something that can be ignored.  In addition to being imposed by the
   SMI, it is also imposed by the SNMP (see the last paragraph in
   Section 4.1 of RFC 3416 [RFC3416]).  It follows that any table with
   enough indexing components to violate this limit cannot be read or
   written using the SNMP and so is unusable.  Hence table design MUST
   take the 128 sub-identifier limit into account.  In some cases it is
   practical to use size constraints on the index variables to enforce
   the limit, and their use is strongly RECOMMENDED in such cases.




OPS Area                  Expires August 2003                  [Page 19]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


4.7.  Notification Definitions

   RFC 2578 Section 8 specifies the rules for notification definitions.
   In particular:

   - Inaccessible objects MUST NOT appear in the OBJECTS clause.

   - For each object type mentioned in the OBJECTS clause, the
     DESCRIPTION clause MUST specify which object instance is to be
     present in the transmitted notification and MUST specify the
     information/meaning conveyed.

   - The OBJECT IDENTIFIER (OID) value assigned to each notification
     type MUST have a next-to-last sub-identifier of zero, so that it is
     possible to convert an SMIv2 notification definition into an SMIv1
     trap definition and back again without information loss (see
     [RFC2576] Section 2.1.2) and possible for a multilingual proxy
     chain to translate an SNMPv2 trap into an SNMPv1 trap and back
     again without information loss (see [RFC2576] Section 3).  In
     addition, the OID assigned to a notification definition MUST NOT
     also be assigned to another definition that results in OID
     registration.  RFC 2578 Section 3.6 lists the constructs that
     create OID registrations.

   Although it is not specifically required by the SMI, it is customary
   (and strongly RECOMMENDED) that notification definitions not be
   registered beneath group definitions, compliance statements,
   capabilities statements, or object definitions (this last is
   especially unwise, as it may result in an object instance and a
   notification definition sharing the same OID).  It is also customary
   (and strongly RECOMMENDED) that the OIDs assigned to notification
   types be leaf OIDs (i.e., that there be no OID registrations
   subordinate to a notification definition).

   In many cases notifications will be triggered by external events, and
   sometimes it will be possible for those external events to occur at a
   sufficiently rapid rate that sending a notification for each
   occurrence would overwhelm the network.  In such cases a mechanism
   MUST be provided for limiting the rate at which the notification can
   be generated.  One mechanism that has been widely used is to require
   the notification generator to use throttling -- that is, to ensure
   that no more than one notification is generated for each event source
   in any given time interval of duration T.  The throttling period T
   MAY be configurable, in which case it would be specified in a MIB
   object, or it MAY be fixed, in which case it would be specified in
   the notification definition.  Examples of the second technique can be
   found in the SNMP-REPEATER-MIB [RFC2108] and in the ENTITY-MIB
   [RFC2737].



OPS Area                  Expires August 2003                  [Page 20]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


4.8.  Compliance Statements

   RFC 2580 Sections 3, 4, and 5 specify the rules for conformance
   groups and compliance statements.  In particular:

   - Every object with a MAX-ACCESS value other than "not-accessible"
     MUST be contained in at least one object group.

   - Every notification MUST be contained in at least one notification
     group.

   - There MUST be at least one compliance statement defined for each
     "standard" MIB module.  It may reside either within that MIB module
     or within a companion MIB module.

   In writing compliance statements there are several points that are
   easily overlooked:

   - An object group or notification group that is not mentioned either
     in the MANDATORY-GROUPS clause or in any GROUP clause of a MODULE-
     COMPLIANCE statement is unconditionally optional with respect to
     that compliance statement.  An alternate way to indicate that an
     object group or notification group is optional is to mention it in
     a GROUP clause whose DESCRIPTION clause states that the group is
     optional.  The latter method is RECOMMENDED (for optional groups
     that are relevant to the compliance statement) in order to make it
     clear that the optional status is intended rather than being the
     result of an act of omission.

   - If there are any objects with a MAX-ACCESS value of read-write or
     read-create for which there is no OBJECT clause that specifies a
     MIN-ACCESS of read-only, then implementations must support write
     access to those objects in order to be compliant with that MODULE-
     COMPLIANCE statement.  This fact sometimes catches MIB module
     authors by surprise.  When confronted with such cases, reviewers
     SHOULD verify that this is indeed what the authors intended, since
     it often is not.

   - On the other side of the coin, MIB module authors need to be aware
     that while a read-only compliance statement is sufficient to
     support interoperable monitoring applications, it is not sufficient
     to support interoperable configuration applications.  A technique
     commonly used in MIB modules that are intended to support both
     monitoring and configuration is to provide both a read-only
     compliance statement and a full compliance statement.  A good
     example is provided by the DIFFSERV-MIB [RFC3289].  Authors SHOULD
     consider using this technique in situations where it is
     appropriate.



OPS Area                  Expires August 2003                  [Page 21]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   Sometimes MIB module authors will want to specify that a compliant
   implementation needs to support only a subset of the values allowed
   by an object's SYNTAX clause.  For accessible objects this may be
   done either by specifying the required values in an object's
   DESCRIPTION clause or by providing an OBJECT clause with a refined
   SYNTAX in a compliance statement.  The latter method is RECOMMENDED
   for most cases, and is REQUIRED if there are multiple compliance
   statements with different value subsets required.  The DIFFSERV-MIB
   [RFC3289] illustrates this point.  The diffServMIBFullCompliance
   statement contains the following contains the OBJECT clause (*)

    OBJECT       diffServDataPathStatus
    SYNTAX       RowStatus { active(1) }
    WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) }
    DESCRIPTION
       "Support for createAndWait and notInService is not required."

   whereas the diffServMIBReadOnlyCompliance statement contains this:

    OBJECT       diffServDataPathStatus
    SYNTAX       RowStatus { active(1) }
    MIN-ACCESS   read-only
    DESCRIPTION
       "Write access is not required, and active is the only status that
       needs to be supported."

   One cannot do this for inaccessible index objects because they cannot
   be present in object groups and cannot be mentioned in OBJECT
   clauses.  There are situations, however, in which one might wish to
   indicate that an implementation is required to support only a subset
   of the possible values of some index in a read-create table.  In such
   cases the requirements MUST be specified either in the index object's
   DESCRIPTION clause (RECOMMENDED if there is only one value subset) or
   in the DESCRIPTION clause of a MODULE-COMPLIANCE statement (REQUIRED
   if the value subset is unique to the compliance statement).
____________________
   (*) There has been some dispute as to whether syntax refinements that
   restrict enumerations (RFC 2578, Section 9) are permitted with TCs,
   as shown in these examples, or are allowed only with the base types
   INTEGER and BITS, as suggested by a strict reading of RFC 2578.  The
   rough consensus of the editors of the SMIv2 documents and the current
   pool of OPS Area MIB reviewers is that they should be allowed with
   TCs.  MIB module authors should be aware that some MIB compilers
   follow the strict reading of RFC 2578 and require that the TC be
   replaced by its base type (INTEGER or BITS) when enumerations are
   refined.  That usage is legal, and it can be found in some older MIB
   modules such as the IF-MIB [RFC2863].




OPS Area                  Expires August 2003                  [Page 22]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


4.9.  Revisions to MIB Modules

   RFC 2578 Section 10 specifies general rules that apply any time a MIB
   module is revised.  Specifically:

   - The MODULE-IDENTITY invocation must be updated to include
     information about the revision.  In particular, the LAST-UPDATED
     clause value MUST be set to the revision time, a REVISION clause
     with the same UTC time and an associated DESCRIPTION clause
     describing the changes MUST be added, and any obsolete information
     in the existing DESCRIPTION, ORGANIZATION, and CONTACT-INFO clauses
     MUST be replaced with up-to-date information.  See Section 4.5
     above for additional requirements that apply to MIB modules that
     are under IETF change control.

   - On the other hand, the module name MUST NOT be changed (except to
     correct typographical errors), existing definitions (even obsolete
     ones) MUST NOT be removed from the MIB module, and descriptors and
     OBJECT IDENTIFIER values associated with existing definitions MUST
     NOT be changed or re-assigned.

   It is important to note that the purpose in forbidding certain kinds
   of changes is to ensure that a revised MIB module is compatible with
   fielded implemantations based on previous versions of the module.
   There are two distinct aspects of this backward compatibility
   requirement.  One is "over the wire" compatibility of agent and
   manager implementations that are based on different revisions of the
   MIB module.  The other is "compilation" compatibility with MIB
   modules that import definitions from the revised MIB module.  The
   rules forbidding changing or re-assigning OBJECT IDENTIFIER values
   are necessary to ensure "over the wire" compatibility;  the rules
   against changing module names or descriptions or removing obsolete
   definitions are necessary to ensure compilation compatibility.

   RFC 2578 Section 10.2 specifies rules that apply to revisions of
   object definitions.  The following guidelines correct some errors in
   these rules and provided some clarifications:

   - Bullet (1) allows the labels of named numbers and named bits in
     SYNTAX clauses of type enumerated INTEGER or BITS to be changed.
     This can break compilation compatibility, since those labels may be
     used by DEFVAL clauses in modules that import the definitions of
     the affected objects.  Therefore, labels of named numbers and named
     bits MUST NOT be changed when revising IETF MIB modules, and they
     SHOULD NOT be changed when revising enterprise MIB modules.

   - Although not specifically permitted in bullets (1) through (8), it
     is generally considered acceptable to add range constraints to the



OPS Area                  Expires August 2003                  [Page 23]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


     SYNTAX clause of an integer-valued object, provided that the
     constraints simply make explicit some value restrictions that were
     implicit in the definition of the object.  The most common example
     is an auxiliary object with a SYNTAX of INTEGER or Integer32 with
     no range constraint.  Since an auxiliary object is not permitted to
     assume negative values, adding the range constraint (0..2147483647)
     cannot possibly result in any "over the wire" change, nor will it
     cause any compilation compatibility problems with a correctly
     written MIB module.  Such a change SHOULD be treated by a reviewer
     as an editorial change, not as a semantic change.

   RFC 2578 Section 10.3 specifies rules that apply to revisions of
   notification definitions.  No clarifications or corrections are
   required.

   RFC 2579 Section 5 specifies rules that apply to revisions of textual
   convention definitions.  The following guideline corrects an error in
   these rules:

   - Bullet (1) allows the labels of named numbers and named bits in
     SYNTAX clauses of type enumerated INTEGER or BITS to be changed.
     This can break compilation compatibility, since those labels may be
     used by DEFVAL clauses in modules that import the definitions of
     the affected TCs.  Therefore, labels of named numbers and named
     bits MUST NOT be changed when revising IETF MIB modules, and they
     SHOULD NOT be changed when revising enterprise MIB modules.

   RFC 2580 Section 7.1 specifies rules that apply to revisions of
   conformance groups.  Two point are worth re-iterating:

   - Objects and notifications MUST NOT be added to or removed from an
     existing object group or notification group.  Doing so could cause
     a compilation failure or (worse) a silent change in the meaning of
     a compliance statement or capabilities statement that refers to
     that group.

   - The status of a conformance group is independent of the status of
     its members.  Thus, a current group MAY refer to deprecated objects
     or notifications.  This may be desirable in certain cases, e.g., a
     set of widely-deployed objects or notifications may be deprecated
     when they are replaced by a more up-to-date set of definitions, but
     the conformance groups that contain them may remain current in
     order to encourage continued implementation of the deprecated
     objects and notifications.

   RFC 2580 Section 7.2 specifies rules that apply to revisions of
   compliance statements.  The following guidelines correct an omission
   from these rules and emphasize one important point:



OPS Area                  Expires August 2003                  [Page 24]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   - RFC 2580 should (but does not) recommend that OBJECT clauses
     specifying support for the original set of values be added to a
     compliance statement when enumerated INTEGER objects or BITS
     objects referenced by the compliance statement have enumerations
     added, assuming that no such clauses are already present.  This is
     necessary in order to avoid a silent change to the meaning of the
     compliance statement.  MIB module authors and reviewers SHOULD
     watch for this to ensure that such OBJECT clauses are added when
     needed.  Note that this may not always be possible to do, since
     affected compliance statements may reside in modules other than the
     one that contains the revised definition(s).

   - The status of a compliance statement is independent of the status
     of its members.  Thus, a current compliance statement MAY refer to
     deprecated object groups or notification groups.  This may be
     desirable in certain cases, e.g., a set of widely-deployed object
     or notification groups may be deprecated when they are replaced by
     a more up-to-date set of definitions, but compliance statements
     that refer to them may remain current in order to encourage
     continued implementation of the deprecated groups.

   RFC 2580 Section 7.3 specifies rules that apply to revisions of
   capabilities statements.  The following guideline corrects an
   omission from these rules:

   - RFC 2580 should (but does not) recommend that VARIATION clauses
     specifying support for the original set of values be added to a
     capabilities statement when enumerated INTEGER objects or BITS
     objects referenced by the capabilities statement have enumerations
     added, assuming that no such clauses are already present.  This is
     necessary in order to avoid a silent change to the meaning of the
     capabilities statement.

   In certain exceptional situations the cost of strictly following the
   SMIv2 rules governing MIB modules revisions may exceed the benefit.
   In such cases the rules can be waived, but when that is done both the
   change and the justification for it MUST be thoroughly documented.
   One example is provided by Section 3.1.5 of RFC 2863, which documents
   the semantic change that was made to ifIndex in the transition from
   MIB-II [RFC1213] to the IF-MIB [RFC2863] and provides a detailed
   justification for that change.  Another example is provided by the
   REVISION clause of the SONET-MIB [RFC2558] that documents raising the
   MAX-ACCESS of several objects to read-write while adding MIN-ACCESS
   of read-only for compatibility with the previous version [RFC1595].

   Authors and reviewers may find it helpful to use tools that can list
   the differences between two revisions of a MIB module.  One such tool
   is smidiff;  see Appendix B for more information.



OPS Area                  Expires August 2003                  [Page 25]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


Appendix A:  MIB Review Checklist

   The purpose of a MIB review is to review the MIB module both for
   technical correctness and for adherence to IETF documentation
   requirements.  The following checklist may be helpful when reviewing
   a draft document:

   1.) I-D Boilerplate -- verify that the draft contains the required
   Internet Draft boilerplate (see http://www.ietf.org/ietf/1id-
   guidelines.txt), including the appropriate statement to permit
   publication as an RFC, and that I-D boilerplate does not contain
   references or section numbers.

   2.) Abstract -- verify that the abstract does not contain references,
   that it does not have a section number, and that its content follows
   the guidelines in [RFC2223bis].

   3.) MIB Boilerplate -- verify that the draft contains the latest
   approved SNMP Network Management Framework boilerplate from the OPS
   area web site (http://www.ops.ietf.org/mib-boilerplate.html).

   4.) IPR Notices -- verify that the draft contains verbatim copies of
   the IPR notices specified in bullets (A) and (B) and if needed bullet
   (D) of Section 10.4 of RFC 2026.

   5.) References -- verify that the references are properly divided
   between normative and informative references, that RFC 2119 is
   included as a normative reference if the terminology defined therein
   is used in the document, that all references required by the
   boilerplace are present, that all MIB modules containing imported
   items are cited as normative references, and that all citations point
   to the most current RFCs unless there is a valid reason to do
   otherwise (for example, it is OK to include an informative reference
   to a previous version of a specification to help explain a feature
   included for backward compatibility).

   6.) Security Considerations Section -- verify that the draft uses the
   latest approved template from the OPS area web site
   (http://www.ops.ietf.org/mib-security.html) and that the guidelines
   therein have been followed.

   7.) IANA Considerations Section -- if the draft contains the initial
   version of an IANA-maintained module, verify that the MODULE-IDENTITY
   invocation contains maintenance instructions that comply with RFC
   2434.  Note that module itself must be in an appendix that will
   disappear after publication and that the IANA Considerations section
   that will appear in the RFC must contain a pointer to that module.




OPS Area                  Expires August 2003                  [Page 26]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   8.) Copyrights -- verify that the draft contains a copyright notice
   on the front page and in the DESCRIPTION clause of the MODULE-
   IDENTITY invocation and there is a full copyright notice section with
   text matching that in recently published RFCs.  Make sure that the
   year is up-to-date in all three places.

   9.) MIB compilation -- examine all error or warning messages
   generated by SMICng and smilint when set to maximum complaint levels
   (exception:  warnings for names longer than 32 characters should be
   ignored).  In general, error messages (E from SMICng, severity <= 4
   from smilint) indicate conditions that MUST be corrected, and warning
   messages (W from SMICng, severity >= 5 from smilint) indicate
   conditions that SHOULD be corrected.  Judgment is required, however,
   because there are situations when a diagnostic message will be issued
   for something that is in fact legitimate (the converse is also true).

   10.) Technical content -- review the actual technical content for
   compliance with the guidelines in this document.  It is particularly
   important to check that DESCRIPTION clauses are sufficiently clear
   and unambiguous to allow interoperable implementations to be created.































OPS Area                  Expires August 2003                  [Page 27]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


Appendix B:  Using smilint to compile MIB modules

   smilint is part of the open-source libsmi package maintained by Frank
   Strauss of the Technical University of Braunschweig;  see
   http://www.ibr.cs.tu-bs.de/projects/libsmi/ for more information and
   downloading instructions.

   By default, the smilint program does only minimal checking, and in a
   MIB review one generally wishes to run the program at maximum
   complaint level, discarding only those warnings pertaining to names
   longer than 32 characters:

   smilint -m -s -l 9 -i namelength-32 <module>

   where <module> is replaced with the file name of the module being
   compiled.  A full pathname is required unless it resides in one of
   the standard MIB directories (see the program documentation for more
   information).

   There is a related utility called smidiff that is useful for checking
   whether updates to a previously-published MIB module conform to the
   SMIv2 rules on revisions.  Command line options similar to those
   above are recommended, except that smidiff does not honor the switch
   "-i namelength-32".  The same effect can be obtained by merging
   stdout and stderr and piping the result through the command

   grep -v 'name .* longer than 32 characters$'

   For those who are unable or unwilling to compile and install smilint
   and smidiff locally, there is an e-mail service that can be used
   instead.  In order to check a MIB module all that is necessary is to
   send an e-mail message to smilint@ibr.cs.tu-bs.de with a blank
   subject line and the MIB module in the message body.  The service
   will run smilint on that MIB module using the default switches shown
   above and will send back an error report by return e-mail.  There is
   also an expert mode that allows multiple MIB module attachments and
   supports arbitrary commands.  Instructions on using it can be
   obtained by sending an e-mail message to smilint@ibr.cs.tu-bs.de with
   "help" in the subject line (less the quotes) and an empty message
   body.  The service will send back a help page via return e-mail.











OPS Area                  Expires August 2003                  [Page 28]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


Appendix C:  Using SMICng to compile MIB modules

   SMICng is a commercial program available from SNMPinfo;  see
   http://www.snmpinfo.com/ for more information.

   As a rule, MIB modules are not compiled directly with SMICng but
   rather are referenced by a SMICng include file, which mentions the
   modules from which symbols are imported and contains any module-
   specific compilation options.  For the purposes of doing MIB reviews,
   selecting maximally picky compilation switches is usually the right
   thing to do.  A sample include file (for the SONET-MIB [RFC2558]) is
   shown below.  Note that this include file was developed for use with
   SMICng 2.2.07, and some changes (particularly to the names of
   included files) may be required for use with later versions.

   -- File: rfc2558.inc       -- SONET-MIB

   -- IMPORTS
   #condInclude "rfc1902.inc" -- SNMPv2-SMI
   #condInclude "rfc1903.inc" -- SNMPv2-TC
   #condInclude "rfc1904.inc" -- SNMPv2-CONF
   #condInclude "rfc2863.inc" -- IF-MIB
   #condInclude "rfc2493.inc" -- PerfHist-TC-MIB

   -- MIB module
   #pushOpt
   -- Add extra strict checking beyond that mandated by SMI
   --   C - check size/range present
   --   W - don't allow size/range for items in a sequence
   --   H - strict ASN.1 for comments
   --   7 - restrict INTEGER values below 2G-1
   --   R - check (in V1) that INDEX objs are read-only
   --   S - require (in V2) that items in compliances be imported
   --   B - strong checking for size/range of items in index clause
   --  0B - act as BITS is builtin
   #addOpt "C W H 7 R S B 0B"

   -- Remove strict checking for benign practices permitted by SMI
   --   9 - no dup OID values with OVAs
   --  0M - check if index items used in VARIABLES or OBJECTS clause
   #removeOpt "9 0M"

   -- Remove relaxed checking beyond that forbidden by SMI
   --   4 - allow non-standard access for objects
   --   5 - allow 'optional' status
   --   6 - no check table, row, seq names
   --   J - allow DEFVAL on Counters
   --   K - allow (in v1) zero valued enums



OPS Area                  Expires August 2003                  [Page 29]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   --   U - allow underbars in names
   --   L - allow (in v1) neg enum values
   --   2 - allow (in v2) use of RFC 1442 types
   --   3 - allow (in v1) INDEX clause on objects
   --   O - allow (in v2) hyphens in labels for enumerated values
   --   P - allow (in v2) hyphens in descriptors(identifiers)
   --   T - no check (in v2) of proper access for items in groups
   --   M - no check (in v2) that NTs and accessible OTs are in a group
   --   F - allow integer/integer32 index items without a range
   --   A - allow (in v2) MIB modules missing a MODULE-IDENTITY
   --   G - allow unused IMPORTS and textual conventions
   --   N - no check (in v2) of access of objects in notifications
   --   I - use (in v1) the v2 rules for checking ACCESS of index items
   --   Z - allow bad table modelling practices
   --  0I - allow use of SMI items and macros without being imported
   --  0N - no check (in v1) of access of leaf items in traps
   --  0S - allow non-matching syntax of sequence items
   #removeOpt "4 5 6 J K U L 2 3 O P T M F A G N I Z 0I 0N 0S"

   -- Relax strict checking for practices permitted (or required) by SMI
   --   V - allow (in v2) a V1 OID or OT as V2 group
   --   E - allow seq item syntax to match TC
   --  0V - allow use dup items in VARIABLES or OBJECTS clause
   #addOpt "V E 0V"

   #condinclude "rfc2558.mi2"
   #condExcludeModule SONET-MIB 0
   #popOpt

   In some cases the switches selected above will cause SMICng to
   complain about something that is not an error.  For instance,
   #removeOpt "G" causes complaints about unused TCs in a module such as
   PerfHist-TC-MIB [RFC2493] that contains nothing but TCs, while
   #removeOpt "Z" will cause complaints about the ifInvStackTable in the
   IF-INVERTED-STACK-MIB [RFC2864] because the indices appear in the
   opposite order than in the IF-MIB's [RFC2863] ifStackTable (which is
   by design).  In such cases the sense of the switches in question
   should be reversed.













OPS Area                  Expires August 2003                  [Page 30]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


Appendix D:  Commonly Used Textual Conventions

   The following TCs are defined in SNMPv2-TC [RFC2579]:

   DisplayString               OCTET STRING (SIZE (0..255))
   PhysAddress                 OCTET STRING
   MacAddress                  OCTET STRING (SIZE (6))
   TruthValue                  enumerated INTEGER
   TestAndIncr                 INTEGER (0..2147483647)
   AutonomousType              OBJECT IDENTIFIER
   VariablePointer             OBJECT IDENTIFIER
   RowPointer                  OBJECT IDENTIFIER
   RowStatus                   enumerated INTEGER
   TimeStamp                   TimeTicks
   TimeInterval                INTEGER (0..2147483647)
   DateAndTime                 OCTET STRING (SIZE (8 | 11))
   StorageType                 enumerated INTEGER
   TDomain                     OBJECT IDENTIFIER
   TAddress                    OCTET STRING (SIZE (1..255))

   Note:  InstancePointer is obsolete and MUST NOT be used.


   The following TC is defined in SNMP-FRAMEWORK-MIB [RFC3411]:

   SnmpAdminString             OCTET STRING (SIZE (0..255))


   The following TCs are defined in INET-ADDRESS-MIB [RFC3291]:

   InetAddressType             enumerated INTEGER
   InetAddress                 OCTET STRING (SIZE (0..255))
   InetAddressPrefixLength     Unsigned32
   InetPortNumber              Unsigned32 (0..65535))
   InetAutonomousSystemNumber  Unsigned32


   The following TCs are defined in TRANSPORT-ADDRESS-MIB [RFC3419]:

   TransportDomain             OBJECT IDENTIFIER
   TransportAddressType        enumerated INTEGER
   TransportAddress            OCTET STRING (SIZE (0..255))


   The following TC is defined in RMON2-MIB [RFC2021]:

   ZeroBasedCounter32          Gauge32




OPS Area                  Expires August 2003                  [Page 31]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   The following TCs are defined in HCNUM-TC [RFC2856]:

   ZeroBasedCounter64          Counter64
   CounterBasedGauge64         Counter64


   The following TCs are defined in IF-MIB [RFC2863]:

   InterfaceIndex              Integer32 (1..2147483647)
   InterfaceIndexOrZero        Integer32 (0..2147483647)


   The following TCs are defined in PerfHist-TC-MIB [RFC2493]:

   PerfCurrentCount            Gauge32
   PerfIntervalCount           Gauge32
   PerfTotalCount              Gauge32


































OPS Area                  Expires August 2003                  [Page 32]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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;  neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.






























OPS Area                  Expires August 2003                  [Page 33]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


Normative References

[RFC2026]   Bradner, S., "The Internet Standards Process -- Revision 3",
            BCP 9, RFC 2026, October 1996.

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirements Levels", BCP 14, RFC 2119, March 1997.

[RFC2223bis]
            Reynolds, J., and R. Braden, "Instructions to Request for
            Comments (RFC) Authors", work in progress (currently
            <draft-rfc-editor-rfc2223bis-03.txt>).

[RFC2434]   Alvestrand, H., "Guidelines for Writing an IANA
            Considerations Section in RFCs", BCP 26, RFC 2434, October
            1998.

[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M. and S. Waldbusser, "Structure of Management
            Information Version 2 (SMIv2)", STD 58, RFC 2578, April
            1999.

[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M.  and S. Waldbusser, "Textual Conventions for
            SMIv2", STD 58, RFC 2579, April 1999.

[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M. and S. Waldbusser, "Conformance Statements for
            SMIv2", STD 58, RFC 2580, April 1999.

[RFC2863]   McCloghrie, K. and F. Kastenholz, "The Interfaces Group
            MIB", RFC 2863, June 2000.

[RFC2864]   McCloghrie, K. and G. Hanson, "The Inverted Stack Table
            Extension to the Interfaces Group MIB", RFC 2864, June 2000.

[RFC2493]   Tesink, K., "Textual Conventions for MIB Modules Using
            Performance History Based on 15 Minute Intervals", RFC 2493,
            January 1999.

[RFC2021]   Waldbusser, S., "Remote Network Monitoring Management
            Information Base Version 2 using SMIv2", RFC 2021, January
            1997.

[RFC2856]   Bierman, A., McCloghrie, K. and R. Presuhn, "Textual
            Conventions for Additional High Capacity Data Types", RFC
            2856, June 2000.




OPS Area                  Expires August 2003                  [Page 34]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


[RFC3291]   Daniele, M., Haberman, B., Routhier, S. and J.
            Schoenwaelder, "Textual Conventions for Internet Network
            Addresses", RFC 3291, May 2002.

[RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
            for Describing Simple Network Management Protocol (SNMP)
            Management Frameworks", STD 62, RFC 3411, December 2002.

[RFC3416]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
            Waldbusser, "Protocol Operations for the Simple Network
            Management Protocol (SNMP)", STD 62, RFC 3416, December
            2002.

[RFC3418]   Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S.
            Waldbusser, "Management Information Base (MIB) for the
            Simple Network Management Protocol (SNMP)", STD 62, RFC
            3418, December 2002.

[RFC3419]   M. Daniele, M. and J. Schoenwaelder, "Textual Conventions
            for Transport Addresses", RFC 3419, December 2002.































OPS Area                  Expires August 2003                  [Page 35]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


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.

[RFC1155]   Rose, M. and K. McCloghrie, "Structure and Identification of
            Management Information for TCP/IP-based Internets", STD 16,
            RFC 1155, May 1990.

[RFC1212]   Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD
            16, RFC 1212, March 1991.

[RFC1215]   Rose, M., "A Convention for Defining Traps for use with the
            SNMP", RFC 1215, March 1991.

[RFC2932]   McCloghrie, K., Farinacci, D., and D. Thaler, "IPv4
            Multicast Routing MIB", RFC 2932, October 2000.

[RFC2576]   Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence
            between Version 1, Version 2, and Version 3 of the
            Internet-standard Network Management Framework", RFC 2576,
            March 2000.

[RFC2108]   de Graaf, K., Romascanu, D., McMaster, D. and K. McCloghrie,
            "Definitions of Managed Objects for IEEE 802.3 Repeater
            Devices using SMIv2", RFC 2108, February 1997.

[RFC2737]   McCloghrie, K. and A. Bierman, "Entity MIB (Version 2)", RFC
            2737, December 1999.

[RFC3289]   Baker, F., Chan, K. and A. Smith, "Management Information
            Base for the Differentiated Services Architecture", RFC
            3289, May 2002.

[RFC1213]   McCloghrie, K. and M. Rose, "Management Information Base for
            Network Management of TCP/IP-based internets - MIB-II", STD
            17, RFC 1213, March 1991.

[RFC1595]   Brown, T. and K. Tesink, "Definitions of Managed Objects for
            the SONET/SDH Interface Type", RFC 1595, March 1994.

[RFC2558]   Tesink, K., "Definitions of Managed Objects for the
            SONET/SDH Interface Type", RFC 2558, March 1999.







OPS Area                  Expires August 2003                  [Page 36]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


Security Considerations

   Implementation and deployment of a MIB module in a system may result
   in security risks that would not otherwise exist.  It is important
   for authors and reviewers of documents that define MIB modules to
   ensure that those documents fully comply with the guidelines in
   http://www.ops.ietf.org/mib-security.html so that all such risks are
   adequately disclosed.

Acknowledgments

   Most of the material on usage of data types was based on input
   provided by Bert Wijnen with assistance from Keith McCloghrie, David
   T. Perkins, and Juergen Schoenwaelder.  Much of the other material on
   SMIv2 usage was taken from an unpublished guide for MIB authors and
   reviewers by Juergen Schoenwaelder.  Some of the recommendations in
   these guidelines are based on material drawn from the on-line SMIv2
   errata list at http://www.ibr.cs.tu-bs.de/ietf/smi-errata/.  Thanks
   to Frank Strauss and Juergen Schoenwaelder for maintaining that list
   and to the contributors who supplied the material for that list.
   Finally, thanks are due to the following individuals whose comments
   on earlier versions of this memo contained many valuable suggestions
   for additions, clarifications, and corrections:  Andy Bierman, David
   Harrington, Keith McCloghrie, David T. Perkins, Randy Presuhn, Dan
   Romascanu, Juergen Schoenwaelder, Frank Strauss, Dave Thaler, and
   Bert Wijnen.

Editor's Address

   C. M. Heard
   600 Rainbow Dr. #141
   Mountain View, CA 94041-2542
   USA

   Phone: +1 650 964 8391
   EMail: heard@pobox.com















OPS Area                  Expires August 2003                  [Page 37]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















OPS Area                  Expires August 2003                  [Page 38]


Internet Draft  Guidelines for MIB Authors and Reviewers   February 2003


   ************************************************************
   * NOTES TO RFC Editor (to be removed prior to publication) *
   *                                                          *
   * 1.) The normative reference [RFC2223bis] currently       *
   * points to a work in progress that is intended to replace *
   * RFC 2223.  Please update that reference to point to the  *
   * forthcoming RFC that replaces RFC 2223, and replace all  *
   * occurrences of "2223bis" with the number of that RFC.    *
   *                                                          *
   * 2.) The I-D <draft-ietf-atommib-rfc2493bis-01.txt> is    *
   * expected to eventually replace RFC 2493.  If that draft  *
   * (or a successor) is published as an RFC prior to or      *
   * concurrently with this document, then the normative      *
   * occurrences of [RFC2493] (i.e., those in Section 4.6.1.2 *
   * and in Appendix D) should be changed to point to that    *
   * RFC, a normative reference to that RFC should be added,  *
   * and the reference [RFC2493] should be moved to the       *
   * informative reference section.  Note that [RFC2493] and  *
   * [RFC2558] must remain as informative references          *
   * supporting Appendix C.                                   *
   *                                                          *
   * 3.) The I-D <draft-ietf-snmpv3-coex-v2-02.txt> (or a     *
   * successor) is expected to eventually replace RFC 2576.   *
   * If that draft (or a successor) is published as an RFC    *
   * prior to or concurrently with this document, then the    *
   * informative reference [RFC2576] should be updated to     *
   * point to the replacement RFC, and the reference tag      *
   * [RFC2576] should be updated to match.                    *
   *                                                          *
   * 4.) The I-D <draft-ietf-entmib-v3-00.txt> (or a          *
   * successor) is expected to eventually replace RFC 2737.   *
   * If that draft (or a successor) is published as an RFC    *
   * prior to or concurrently with this document, then the    *
   * informative reference [RFC2737] should be updated to     *
   * point to the replacement RFC, and the reference tag      *
   * [RFC2737] should be updated to match.                    *
   *                                                          *
   ************************************************************













OPS Area                  Expires August 2003                  [Page 39]