home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-perkins-02.txt < prev    next >
Text File  |  1997-06-13  |  29KB  |  743 lines
  1.  
  2. INTERNET-DRAFT           Expires December 1997           INTERNET-DRAFT
  3.  
  4. Draft                  A Clarification of STATUS           June 7, 1997
  5.  
  6.  
  7.                          A Clarification of the
  8.                              STATUS Clause
  9.                           in SNMP MIB Modules
  10.  
  11.                     <draft-rfced-info-perkins-02.txt>
  12.  
  13.                               June 7, 1997
  14.  
  15.                             David T. Perkins
  16.                          dperkins@snmpinfo.com
  17.  
  18.  
  19. 1.  Status of this Memo
  20.  
  21.    This document is an Internet Draft.  Internet Drafts are working
  22.    documents of the Internet Engineering Task Force (IETF), its Areas,
  23.    and its Working Groups. Note that other groups may also distribute
  24.    working documents as Internet Drafts.
  25.  
  26.    Internet Drafts are draft documents valid for a maximum of six
  27.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  28.    other documents at any time.  It is not appropriate to use Internet
  29.    Drafts as reference material or to cite them other than as a
  30.    "working draft" or "work in progress."
  31.  
  32.    To learn the current status of any Internet-Draft, please check the
  33.    "1id-abstracts.txt" listing contained in the internet-drafts Shadow
  34.    Directories on:
  35.  
  36.          ftp.is.co.za (Africa)
  37.          nic.nordu.net (Europe)
  38.          ds.internic.net (US East Coast)
  39.          ftp.isi.edu (US West Coast)
  40.          munnari.oz.au (Pacific Rim)
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Expires 12/07/97                                               [Page 1]
  59. Draft                  A Clarification of STATUS           June 7, 1997
  60.  
  61.  
  62. 2.  Introduction
  63.  
  64. This memo is informational.  It specifies a clarification of the meaning
  65. and use of the STATUS clause in Simple Network Management Protocol
  66. (SNMP) Management Information Base (MIB) modules, which are defined by
  67. the Structure of Management Information (SMI).  There are two versions
  68. of the SMI.  The first, called SMIv1, is defined by RFCs 1155[1],
  69. 1212[2], and 1215[3].  The second, called SMIv2, is defined by RFCs
  70. 1902[4], 1903[5], and 1904[6].  Many of the MIB module constructs
  71. defined by the SMIs such as OBJECT-IDENTITY, OBJECT-TYPE, and
  72. NOTIFICATION-TYPE contain the STATUS clause.  However, the SMIs do not
  73. provide a complete definition of the STATUS clause, nor do they provide
  74. guidance to MIB designers and users on the interpretation and action
  75. required dependent upon the value or change of value for a STATUS
  76. clause.  Users include agent and application developers, and operators
  77. of SNMP-managed networks.
  78.  
  79. This memo specifies a clarification for both version 1 and version 2 of
  80. the SNMP SMI, which is a standard for the Internet community.
  81.  
  82.  
  83. 3.  Background
  84.  
  85. The STATUS clause was first defined in "Structure and Identification of
  86. Management Information for TCP/IP-based Internets," RFC 1065[7].  This
  87. document lists the possible status values of object type definitions as
  88. "mandatory," "optional," and "obsolete," but does not contain an
  89. interpretation of these values.  The document does provide the
  90. definition of the prime directive of MIB design (in section 5), which
  91. is:
  92.  
  93.     New versions of MIB modules may:
  94.  
  95.       (1) change the status of object types to obsolete (if necessary),
  96.           but may not delete their definitions;
  97.  
  98.       (2) define new columnar object types for an existing table; or
  99.  
  100.       (3) define entirely new object types.
  101.  
  102.     New versions may not:
  103.  
  104.       (1) change the semantics of any previously defined object type.
  105.  
  106.  
  107. The original SMI definition was replaced by "Structure and
  108. Identification of Management Information for TCP/IP-based Internets,"
  109. RFC 1155[1].  However, no changes were made to the definition of the
  110. STATUS clause or the prime directive for MIB design.
  111.  
  112.  
  113.  
  114.  
  115. Expires 12/07/97                                               [Page 2]
  116. Draft                  A Clarification of STATUS           June 7, 1997
  117.  
  118.  
  119. The document, "Concise MIB Definitions," RFC 1212[2], was written after
  120. RFC 1155 to allow MIB designers to write MIB modules in a concise
  121. format.  The format combined the two formats specified in RFC 1155 for
  122. writing definitions of managed objects. Also, RFC 1212 extended the
  123. STATUS clause with the addition of the value "deprecated," and kept the
  124. existing values of "mandatory," "optional," and "obsolete."  Note that
  125. RFC 1212 did not define the meaning of the new value "deprecated."  The
  126. only definition of the STATUS clause found in RFC 1212 is:
  127.  
  128.     4.1.3.  Mapping of the STATUS clause
  129.  
  130.       The STATUS clause, which must be present, defines the
  131.       implementation support required for that object type.
  132.  
  133. Surprisingly, a definition of the value "deprecated" is specified in
  134. "Management Information Base for Network Management of TCP/IP-based
  135. internets: MIB-II," RFC 1213[8], which uses the concise format for
  136. defining the IETF core objects.  It is surprising, since the documents
  137. that describe the language used to write MIB modules do not define use
  138. of the STATUS clause, and the document that contains an example of a MIB
  139. module, defines use of the STATUS clause.
  140.  
  141. The text from RFC 1213 describing the value of "deprecated" is:
  142.  
  143.     3.1.  Deprecated Objects
  144.  
  145.     In order to better prepare implementors for future changes in the
  146.     MIB, a new term "deprecated" may be used when describing an object.
  147.     A deprecated object in the MIB is one which must be supported, but
  148.     one which will most likely be removed from the next version of the
  149.     MIB (e.g., MIB-III).
  150.  
  151.     MIB-II marks one object as being deprecated:
  152.  
  153.        atTable
  154.  
  155.     As a result of deprecating the atTable object, the entire Address
  156.     Translation group is deprecated.
  157.  
  158.     Note that no functionality is lost with the deprecation of these
  159.     objects: new objects providing equivalent or superior functionality
  160.     are defined in MIB-II.
  161.  
  162. RFC 1213 contains additional text to define the concept of conformance,
  163. which is not previously defined in SMIv1. The text from RFC 1213,
  164. section 5 is:
  165.  
  166.     MIB-II, like its predecessor, the Internet-standard MIB, contains
  167.     only essential elements.  There is no need to allow individual
  168.     objects to be optional.  Rather, the objects are arranged into the
  169.     following groups:
  170.  
  171.  
  172. Expires 12/07/97                                               [Page 3]
  173. Draft                  A Clarification of STATUS           June 7, 1997
  174.  
  175.  
  176.  
  177.        - System
  178.        - Interfaces
  179.        - Address Translation (deprecated)
  180.        - IP
  181.        - ICMP
  182.        - TCP
  183.        - UDP
  184.        - EGP
  185.        - Transmission
  186.        - SNMP
  187.  
  188.     These groups are the basic unit of conformance. This method is as
  189.     follows: if the semantics of a group is applicable to an
  190.     implementation, then it must implement all objects in that group.
  191.     For example, an implementation must implement the EGP group if and
  192.     only if it implements the EGP.
  193.  
  194.     There are two reasons for defining these groups: to provide a means
  195.     of assigning object identifiers; and, to provide a method for
  196.     implementations of managed agents to know which objects they must
  197.     implement.
  198.  
  199. What may not be obvious from this history is that the STATUS clause is
  200. used for two different purposes in SMIv1 format MIB modules.  The first
  201. use is to specify the status of a definition, that is, specify whether a
  202. definition is valid or invalid.  This is needed, since the prime
  203. directive for MIB design does not allow a definition to be semantically
  204. changed or "removed."  A definition may only be "retired" and, if a new
  205. definition is created, the new one must use a new identity.  The second
  206. use of the STATUS clause is to specify conformance requirements.  To
  207. eliminate the confusion caused by the two uses of one clause, the second
  208. version of the SMI for SNMP changed the STATUS clause so that it
  209. specifies only the validity of a definition.
  210.  
  211. The document, "Structure of Management Information for version 2 of the
  212. Simple Network Management Protocol (SNMPv2)," RFC 1442[9], and its
  213. replacement, RFC 1902[4], define values for the STATUS clause as
  214. "current," "deprecated," and "obsolete."  Other MIB module language
  215. constructs were added to specify conformance requirements[6][11].  The
  216. STATUS clause is used in all but one of the SMIv2 MIB module language
  217. constructs, which are OBJECT-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
  218. TEXTUAL-CONVENTION, OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE,
  219. and AGENT-CAPABILITIES. The lone exception is MODULE-IDENTITY.
  220.  
  221. For all constructs (except AGENT-CAPABILITIES), the text describing the
  222. STATUS clause is the following:
  223.  
  224.       The STATUS clause, which must be present, indicates whether this
  225.       definition is current or historic.
  226.  
  227.  
  228.  
  229. Expires 12/07/97                                               [Page 4]
  230. Draft                  A Clarification of STATUS           June 7, 1997
  231.  
  232.  
  233.       The values "current", and "obsolete" are self-explanatory.  The
  234.       "deprecated" value indicates that the definition is obsolete, but
  235.       that an implementor may wish to support it to foster
  236.       interoperability with older implementations.
  237.  
  238. The text for the STATUS clause for AGENT-CAPABILITIES is the following:
  239.  
  240.       The STATUS clause, which must be present, indicates whether this
  241.       definition is current ("current") or historic ("obsolete").
  242.  
  243. In both cases, it is clear that the STATUS clause in SMIv2 is used only
  244. to describe the status of the definition and not the implementation
  245. requirements.  However, the definition leaves much interpretation to MIB
  246. designers and users.  Unfortunately, the interpretations by different
  247. MIB designers and between designers and users has been quite different.
  248.  
  249. The next section describes the meaning of each value of the STATUS
  250. clause with a high degree of precision.  It also presents a table of
  251. actions for agent and management application developers for each value.
  252.  
  253.  
  254. 4.  The STATUS Clause Defined
  255.  
  256. The STATUS clause is used to specify the validity of a definition. A
  257. valid definition has the following properties:
  258.  
  259.      1.   It is well conceived.  The definition is precise, unambiguous,
  260.           complete, and applicable across a wide scope.
  261.  
  262.      2.   It is relevant.  It is useful and has been used (or soon will
  263.           be used) for implementation.
  264.  
  265.  
  266. On the other hand, an invalid definition has the following properties:
  267.  
  268.      1.   It is flawed.  This can be due to technical inaccuracies or to
  269.           an extremely limited scope of applicability.
  270.  
  271.      2.   It is no longer relevant.  The definition was redundant with
  272.           another, never implemented, or its implementation provided
  273.           little or no benefit.
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286. Expires 12/07/97                                               [Page 5]
  287. Draft                  A Clarification of STATUS           June 7, 1997
  288.  
  289.  
  290. Invalid definitions can be further divided.  The small, but important
  291. class of definitions that are called "deprecated" have the following
  292. properties:
  293.  
  294.      1.   The definition is limited in applicability.  Another
  295.           definition may have been created with a wider scope of
  296.           applicability.
  297.  
  298.      2.   The definition has limited implementation, possibly due to
  299.           cost of implementation.  Another definition may have been
  300.           created with a lower implementation cost to increase the
  301.           probability of implementation.
  302.  
  303. Thus, the values for the STATUS clause and their meanings are the
  304. following:
  305.  
  306.      current(SMIv2) - the definition is valid.
  307.  
  308.      mandatory(SMIv1) - the definition is valid and implementation is
  309.      required for conformance.
  310.  
  311.      Optional(SMIv1) - the definition is valid, however, implementation
  312.      is not required for conformance.
  313.  
  314.      deprecated(SMIv1 & SMIv2) - the definition is valid in limited
  315.      circumstances (and in SMIv1, implementation is required for
  316.      conformance), but has been replaced by another. The new definition
  317.      typically encompasses a wider scope, or has been changed to ease
  318.      implementation.
  319.  
  320.      obsolete(SMIv1 & SMIv2) - the definition is not valid. It was found
  321.      to be flawed; could not be implemented; was redundant or not
  322.      useful; or was no longer relevant.  The definition may, but need
  323.      not be, replaced with another.
  324.  
  325.  
  326. 5.  MIB Module Life Cycle
  327.  
  328. MIB modules are designed, reviewed, published, implemented, and
  329. maintained.  The prime directive for MIB design requires that once a
  330. definition has been published, that its semantics cannot be changed and
  331. that it cannot be "removed."  For the IETF, published means posted as an
  332. RFC.  Posting a work-in-progress in the internet-drafts directory does
  333. not qualify as being published.  The IETF standards process requires
  334. that standard-track documents be reviewed at each level before
  335. advancement.  At each review, definitions are checked to determine if
  336. they have been implemented and are useful.  If not, then a new and
  337. better definition is created, or the definition is retired.  The
  338. following diagram shows the life cycle of definitions:
  339.  
  340.  
  341.  
  342.  
  343. Expires 12/07/97                                               [Page 6]
  344. Draft                  A Clarification of STATUS           June 7, 1997
  345.  
  346.  
  347.         definition
  348.          created
  349.             |
  350.             V
  351.   ----------------------
  352.   |  STATUS is current |<----
  353.   ----------------------    |no change
  354.             |               |in status
  355.        definition           |
  356.        is reviewed          ^
  357.             |              / \
  358.             |            /     \         definition is
  359.             ---------> <  result > --->  usable, but
  360.                          \     /         needs update
  361.                            \ /               |
  362.                             V                |---> STATUS changed to
  363.                             |                |     "deprecated" on
  364.                             |                |     existing definition
  365.                             |                |     and DESCRIPTION
  366.                             |                |     clause updated.
  367.                             V                |
  368.                       definition:            |---> new definition
  369.                        1) could not be             created (with STATUS
  370.                           implemented;             of "current").
  371.                        2) is redundant;
  372.                        3) is not useful; or
  373.                        4) is not relevant.
  374.                             |
  375.                             |--- > STATUS changed to "obsolete"
  376.                             |      on existing definition and
  377.                             |      DESCRIPTION clause updated.
  378.                             |
  379.                          optionally
  380.                             |
  381.                             |--- > new definition created
  382.                                    (with STATUS of "current")
  383.  
  384. MIB designers try to accomplish conflicting goals in creating
  385. definitions in a MIB module.  The definitions must describe the current
  386. implementation of a technology, but must also try to anticipate future
  387. implementations and changes in the technology.  If definitions map too
  388. tightly to current implementations, then any additions or changes in the
  389. implementation of the technology will most likely break the mapping,
  390. resulting in the definitions becoming useless. However, if the
  391. definitions are too abstract or too broad in scope, they may not be
  392. understood or used correctly.  Also, extensive definitions will be more
  393. costly to implement and test.
  394.  
  395. Development and use of products containing implementations of
  396. definitions from MIB modules happens over time.  Usually, managed
  397. systems containing agents that support the definitions are fielded three
  398.  
  399.  
  400. Expires 12/07/97                                               [Page 7]
  401. Draft                  A Clarification of STATUS           June 7, 1997
  402.  
  403.  
  404. to nine months (or more) before sophisticated management applications.
  405. Management capabilities must be used to learn which parts are useful.
  406.  
  407. Experience has shown that MIB designers cannot always get all
  408. definitions right at the time the MIB is first published.  Also,
  409. different sets of agent and management application developers use the
  410. definitions in a MIB module at different points in the life cycle of a
  411. MIB module.  For example, "bleeding edge" developers may be the
  412. designers of the original MIB module.  Developers of mass market
  413. products may not develop implementations until after the MIB module has
  414. reached "Full Standard" status.
  415.  
  416.  
  417. 6.  Actions for Users of Definitions of Objects
  418.  
  419. Below is a list of actions for agent and management developers based on
  420. the current value of STATUS for an object defined with the OBJECT-TYPE
  421. construct, and actions based on a change of a status value:
  422.  
  423.  
  424. 6.1.  Object created or has a STATUS of mandatory or current
  425.  
  426. Agent developers should implement the object if the resource modeled by
  427. the definition is present on the system.
  428.  
  429. Management application developers can use the object, if needed, by
  430. their application.
  431.  
  432.  
  433. 6.2.  Object created or has STATUS of optional
  434.  
  435. Note that this value, found only in SMIv1,  is not allowed in standard-
  436. track MIB modules.
  437.  
  438. Agent developers should treat the object as if the definition had a
  439. STATUS of current.  Whether the object is implemented depends on the
  440. requirements.
  441.  
  442. Management application developers should not use the object, since it
  443. probably is not well conceived and probably not widely implemented.
  444.  
  445.  
  446. 6.3.1.  Object has STATUS of deprecated
  447.  
  448. Agent developers should treat the object as if the definition had a
  449. STATUS of current.  Whether the object is implemented depends on the
  450. requirements for compatibility with existing management applications.
  451. The replacement object should be implemented if the deprecated object is
  452. implemented.
  453.  
  454.  
  455.  
  456.  
  457. Expires 12/07/97                                               [Page 8]
  458. Draft                  A Clarification of STATUS           June 7, 1997
  459.  
  460.  
  461. Management application developers should treat the object as if the
  462. definition had a status of current.  The object should not be used as
  463. the primary access to the management information. Instead, the
  464. replacement object should be used.  However, if compatibility is
  465. required with existing agents, then the application should first try to
  466. access the replacement object, and only if it is not implemented, should
  467. the application try to access the object whose definition has a STATUS
  468. of deprecated.
  469.  
  470.  
  471. 6.3.2  Object has STATUS changed to deprecated
  472.  
  473. Agent developers should implement the replacement object for the next
  474. released version of the agent.  Whether the object whose STATUS is
  475. deprecated is removed depends on the resources needed to support it and
  476. the requirement for compatibility with existing management applications.
  477.  
  478.  
  479. Management application developers should implement the replacement
  480. object for the next released version of the application. The primary
  481. access to the management information should be changed to use the
  482. replacement object.  However, if compatibility is required with existing
  483. agents, then the application should first try to access the replacement
  484. object, and only if it is not implemented should the application try to
  485. access the object whose definition had its STATUS changed to deprecated.
  486.  
  487.  
  488. 6.4.1.  Object has STATUS of obsolete
  489.  
  490. Agent developers should not implement the object.  If a replacement
  491. object has been defined, it should be implemented if applicable.
  492.  
  493. Management application developers should not use the object.
  494.  
  495.  
  496. 6.4.2.  Object has STATUS changed to obsolete
  497.  
  498. Agent developers may remove the object.  If a replacement object has
  499. been defined, it should be implemented if applicable.
  500.  
  501. Management application developers should remove use of the object in
  502. applications and review their application for proper design.
  503.  
  504.  
  505. 7.  An Invalid Implementation Approach for Agent Developers
  506.  
  507. The developer of an agent implementation may not have access to the
  508. value of a "mandatory" object.  In this case, GET requests of the object
  509. must return "noSuchName" errors for SNMPv1 and "noSuchObject" exception
  510. values for SNMPv2.  SET requests of the object must return "noSuchName"
  511. errors in SNMPv1 and "noAccess" errors in SNMPv2.  GETNEXT (and GETBULK
  512.  
  513.  
  514. Expires 12/07/97                                               [Page 9]
  515. Draft                  A Clarification of STATUS           June 7, 1997
  516.  
  517.  
  518. in SNMPv2) requests must simply return the next lexicographically
  519. ordered object.  Unimplemented objects in a mandatory group for a
  520. compliance specification result in the agent being labeled as "non-
  521. compliant" to that specification.  However, such an agent is still
  522. compliant to the SNMP protocol.  On the other hand, an agent that
  523. returns "benign" values for readable objects or does not change
  524. writeable objects is also labeled as "non-compliant" to the conformance
  525. specification and is also non-compliant to the SNMP protocol
  526. specification.  Note that there are a few objects, such as
  527. ipRouteMetric3, whose definition includes special values to indicate
  528. certain conditions.  These special values are not "benign" values.  That
  529. is, the implementation of the object is only compliant when the values
  530. of the object truthfully reflect those in the managed resource.  The
  531. special value of -1 for ipRouteMetric3 indicates that the routing metric
  532. is not used by the routing protocol.
  533.  
  534. 8.  MIB Update Requirements
  535.  
  536. The MIB module life cycle diagram, shown in section 5, indicates what
  537. must occur when a MIB module is updated.  Note that the text in section
  538. 10 of RFC 1902 specifies rules for updating MIB modules. Several of
  539. these rules are clarified below:
  540.  
  541.      1.   The MODULE-IDENTITY construct for the MIB module must be
  542.           updated to include information about the revision.  This
  543.           minimally includes updating the date on the LAST-UPDATED
  544.           clause and adding a pair of REVISION and DESCRIPTION clauses.
  545.           The name of the MIB module is not changed when its contents
  546.           are changed.
  547.  
  548.      2.   For each item with a change in the value of the STATUS clause,
  549.           the text of the DESCRIPTION clause must be updated to reflect
  550.           the change.  When the status is changed to "deprecated," then
  551.           the description must specify the replacement item and range of
  552.           applicability.  When the status is changed to "obsolete," then
  553.           the description must indicate the reason and must specify the
  554.           replacement item if one has been created.  Typically, the
  555.           original text of the description is eliminated so that there
  556.           is no mistake over the status of the item.
  557.  
  558.      3.   A change of status of an item will affect the status of items
  559.           that depend on it. These dependent items must be reviewed
  560.           updated.  The dependent items include object and notification
  561.           groups, module compliances, object types, notification types
  562.           and textual conventions.  For example, if the status of an
  563.           object type changes, then the status of each notification
  564.           type, object group, and module compliance that includes the
  565.           object type needs to be updated.  Additionally, new instances
  566.           of these items most likely need to be created that include the
  567.           replacement object type.  Consider when the status of a
  568.           textual convention is modified.  Each object type and textual
  569.  
  570.  
  571. Expires 12/07/97                                              [Page 10]
  572. Draft                  A Clarification of STATUS           June 7, 1997
  573.  
  574.  
  575.           convention referencing (and dependent on) that textual
  576.           convention must be reviewed.  These dependent items must be
  577.           changed.  The change may be to use a replacement or to use the
  578.           type from the original textual convention.  For any change,
  579.           the result must not modify the semantics of a dependent item.
  580.  
  581.  
  582. 8.1.  Example of DESCRIPTION Update
  583.  
  584. When the status of an item is changed, the SMI requires that the text of
  585. the DESCRIPTION clause be updated.  Below are a few examples:
  586.  
  587.   -- The status of an object changed from "current" to "deprecated"
  588.  
  589.     atNetAddress OBJECT-TYPE
  590.       SYNTAX  NetworkAddress
  591.       ACCESS  read-write
  592.       STATUS  deprecated
  593.       DESCRIPTION
  594.         "The NetworkAddress (e.g., the IP address)
  595.         corresponding to the media-dependent `physical'
  596.         address.
  597.         **NOTE: this object is deprecated and replaced by
  598.         ipNetToMediaNetAddress from table ipNetToMediaTable
  599.         and by similar objects in protocol specific tables."
  600.       ::= { atEntry 3 }
  601.  
  602.  
  603. -- The status of an object changed from "current" to "obsolete"
  604.  
  605.     ospfAuthType OBJECT-TYPE
  606.       SYNTAX   Integer32
  607.       MAX-ACCESS   read-create
  608.       STATUS   obsolete
  609.       DESCRIPTION
  610.         "**NOTE: this object is obsolete.  Authentication is done
  611.         on each interface.  See table ospfIfTable and object
  612.         ospfIfAuthType."
  613.       REFERENCE
  614.         "OSPF Version 2, Appendix E Authentication"
  615.       DEFVAL { 0 }        -- no authentication, by default
  616.       ::= { ospfAreaEntry 2 }
  617.  
  618.  
  619. 8.2.  Don't Remove Obsolete Items
  620.  
  621. The "obsolete" value is meant to document the existence of a retired
  622. definition.  However, it can be observed (and even in IETF standard-
  623. track MIB modules) that these definitions have been removed in updated
  624. versions of the containing document.  This is bad, and also is counter
  625.  
  626.  
  627.  
  628. Expires 12/07/97                                              [Page 11]
  629. Draft                  A Clarification of STATUS           June 7, 1997
  630.  
  631.  
  632. to the prime directive for MIB design.  No definitions may ever be
  633. removed from published MIB modules!
  634.  
  635. Of course, it is possible to create a new MIB module to contain obsolete
  636. definitions.  For example, RFC 1232 contains a MIB module for managing
  637. DS1 interfaces.  It was replaced by RFC 1406, which replaced all
  638. definitions in RFC 1232.  The items defined in RFC 1232 were not
  639. included in RFC 1406 and marked as "obsolete."  Thus, RFC 1406 is not in
  640. compliance with the prime directive for MIB design.  The action by the
  641. WG was an exception case.  There were approximately 50 objects in RFC
  642. 1232 that were made obsolete by the publishing of RFC 1406.  Including
  643. the definitions for them in the MIB module in RFC 1406 may have obscured
  644. replacement definitions or have confused the document readers.  These
  645. problems should have been addressed by either ordering the definitions
  646. in the MIB module so that the obsolete ones were placed after the
  647. current ones, or preferably the obsolete definitions moved to another
  648. MIB module (contained in RFC 1406).  Either one of these approaches
  649. would be compliant to the prime directive for MIB design.
  650.  
  651.  
  652. 8.3.  Consistency Requirement
  653.  
  654. At any point in time, the set of published MIB modules must be
  655. consistent and their union must contain every item that has ever been
  656. defined.
  657.  
  658.  
  659. 9.  Acknowledgments
  660.  
  661. Thanks go to Evan McGinnis for his review, and to David Waitzman for his
  662. suggestions.
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685. Expires 12/07/97                                              [Page 12]
  686. Draft                  A Clarification of STATUS           June 7, 1997
  687.  
  688.  
  689. 10.  References
  690.  
  691.  
  692. [1]  K. McCloghrie, M. Rose, "Structure and Identification of Management
  693.      Information for TCP/IP-based Internets", RFC 1155, 05/10/1990.
  694.  
  695. [2]  K. McCloghrie, M. Rose, "Concise MIB Definitions", RFC 1212,
  696.      03/26/1991.
  697.  
  698. [3]  M. Rose, "A Convention for Defining Traps for use with the SNMP",
  699.      RFC 1215, 03/27/1991.
  700.  
  701. [4]  J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Structure of
  702.      Management Information for Version 2 of the Simple Network
  703.      Management Protocol (SNMPv2)", RFC 1902, 01/22/1996.
  704.  
  705. [5]  J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Textual
  706.      Conventions for Version 2 of the Simple Network Management Protocol
  707.      (SNMPv2)", RFC 1903, 01/22/1996.
  708.  
  709. [6]  J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Conformance
  710.      Statements for Version 2 of the Simple Network Management Protocol
  711.      (SNMPv2)", RFC 1904, 01/22/1996.
  712.  
  713. [7]  K. McCloghrie, M. Rose, "Structure and identification of management
  714.      information for TCP/IP-based internets", RFC 1065, 08/01/1988
  715.  
  716. [8]  K. McCloghrie, M. Rose, "Management Information Base for Network
  717.      Management of TCP/IP-based internets: MIB-II", RFC1213, 03/26/1991.
  718.  
  719. [9]  J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Structure of
  720.      Management Information for version 2 of the Simple Network
  721.      Management Protocol (SNMPv2)", RFC 1442, 05/03/1993.
  722.  
  723. [10]  J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Textual
  724.      Conventions for version 2 of the Simple Network Management Protocol
  725.      (SNMPv2)", RFC 1443, 05/03/1993.
  726.  
  727. [11] J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Conformance
  728.      Statements for version 2 of the Simple Network Management Protocol
  729.      (SNMPv2)", RFC 1444, 05/03/1993.
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742. Expires 12/07/97                                              [Page 13]
  743.