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-perkins-smi-clarification-00.txt < prev    next >
Text File  |  1996-07-31  |  27KB  |  703 lines
  1.  
  2. INTERNET-DRAFT            Expires January 1997            INTERNET-DRAFT
  3.  
  4. Draft                      SMI Clarification               July 30, 1996
  5.  
  6.  
  7.                             A Clarification
  8.                                 of SMIv2
  9.  
  10.                   <draft-perkins-smi-clarification-00.txt>
  11.  
  12.                              July 30, 1996
  13.  
  14.                             David T. Perkins
  15.                          dperkins@scruznet.com
  16.  
  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 1/30/1997                                               [Page 1]
  59.  
  60. Draft                      SMI Clarification               July 30, 1996
  61.  
  62.  
  63.  
  64. 2. Introduction
  65.  
  66. This memo is a clarification of the structure of management information
  67. (SMI) for version 2 of the Simple Network Management Protocol (SNMP).
  68. SMIv2 is defined in RFCs 1902[1], 1903[2] and 1904[4].  This version is
  69. a rough first draft as requested by the SNMPv2 WG at the SMI
  70. Documentation BOF during the June 1996 IETF.
  71.  
  72. This memo assumes that the reader has already read RFCs 1902-4 and
  73. generally understands the concepts defined in these documents.
  74.  
  75. SMIv2 includes the definitions for the following items:
  76.      1.  The model of management information;
  77.      2.  The data types for management information;
  78.      3.  The language for writing MIB modules;
  79.      4.  Administrative assignments of a few key elements;
  80.      5.  Rules for modifying published MIB modules;
  81.      6.  A preferred mechanism to create and delete instances of
  82.          columnar information through SNMP operations; and
  83.      7.  A core set of textual conventions.
  84.  
  85. The purpose of this document is to identify those areas related to the
  86. definition of data types and the language of writing MIB modules that
  87. are incomplete, ambiguous, incomprehensible or inconsistent and provide
  88. clarifications.  It is not the goal of this document to change or extend
  89. the data types or the MIB module language.
  90.  
  91. The data types and language for writing MIB modules are defined using a
  92. combination of ASN.1 specifications and textual prose.  This approach to
  93. define these items is fatally flawed for the following reasons:
  94.      1.  The dialect of the ASN.1 language used for these definitions
  95.          was an early version and is now obsolete.  Thus, its
  96.          specification is not generally available.
  97.      2.  There is not a clean separation between the elements used to
  98.          define the MIB module language and the base definitions
  99.          specified in the MIB module language.
  100.      3.  The ASN.1 specifications used to define the MIB module language
  101.          are incorrect.
  102.      4.  A few constructs from programming languages, not found in
  103.          ASN.1, were added to MIB module language.
  104.      5.  A few "misinterpretations" of the ASN.1 language were allowed
  105.          as constructs of the MIB module language.
  106.      6.  The MIB module language uses different terminology than ASN.1
  107.          for a few key common elements of the languages.
  108.  
  109.  
  110. 3. Data Types
  111.  
  112. The term "data types" refers to the range and meaning of values of
  113. management information.  The primary purpose of the MIB module language
  114.  
  115.  
  116. Expires 1/30/1997                                               [Page 2]
  117.  
  118. Draft                      SMI Clarification               July 30, 1996
  119.  
  120.  
  121. is to specify definitions of management information.  Each definition
  122. includes the data type of the management information.  The data types
  123. allowed in the MIB module language are a subset of the ASN.1 UNIVERSAL
  124. types, several ASN.1 APPLICATION types defined in the SMI, size or range
  125. limited versions of these types (called sub-types), pseudo-types, and
  126. semantically restricted versions of previously defined types (called
  127. textual conventions).  The SNMPv2 base data types consist of the ASN.1
  128. UNIVERSAL types, the ASN.1 APPLICATION types, and the pseudo-types.
  129.  
  130.  
  131. 3.1 Pseudo-types
  132.  
  133. An item that has the look and function of an ASN.1 type, but is not
  134. strictly an ASN.1 type is called a pseudo-type.  The SMI doesn't include
  135. this terminology, and instead calls it a construct.  However, the term
  136. pseudo-type closely describes these elements and term is used throughout
  137. this memo.  The definitions of the OBJECT-TYPE and TEXTUAL-CONVENTION
  138. macros are incorrect in their attempt to add the BITS pseudo-type.
  139. Also, the MODULE-COMPLIANCE and AGENT-CAPABILITIES macros lack allowing
  140. the BITS pseudo-type; and the BITS pseudo-type as currently defined can
  141. not be specified in a SEQUENCE definition.  One valid approach in ASN.1
  142. to specify the BITS pseudo-type can be found in "The BITS Pseudo-type
  143. for SNMPv2 SMI"[5].
  144.  
  145. Note that the current approach to defining BITS makes it appear that the
  146. BITS pseudo-type is built into ASN.1 and thus does not need to be
  147. imported before it is used.  The valid approach specified in [5]
  148. requires that the BITS pseudo-type be imported before it can be used.
  149.  
  150.  
  151. 3.2 SNMP Data Types
  152.  
  153. The base data types for SNMP are not clearly identified and defined.
  154. The allowed data types are:
  155.      1.  ASN.1 UNIVERSAL - INTEGER (Integer32), OCTET STRING, and OBJECT
  156.          IDENTIFIER
  157.      2.  ASN.1 APPLICATION - Unsigned32, Gauge32, Counter32, Counter64,
  158.          TimeTicks, IpAddress, and Opaque
  159.      3.  Pseudo-type - BITS
  160.  
  161. The remainder of this section points out the problem definitions and
  162. provides clarifications.
  163.  
  164. 3.2.1 Integer32
  165.  
  166. The first of these data types with problem are INTEGER and Integer32.
  167. The definition of Integer32 in the SMI is incorrect, since an ASN.1
  168. UNIVERSAL type may be defined only in the ASN.1 specification. This
  169. problem can easily corrected by modifying the line:
  170.     Integer32 ::=
  171.         [UNIVERSAL 2]
  172.  
  173.  
  174. Expires 1/30/1997                                               [Page 3]
  175.  
  176. Draft                      SMI Clarification               July 30, 1996
  177.  
  178.  
  179.             IMPLICIT INTEGER (-2147483648..2147483647)
  180.  
  181. to read:
  182.     Integer32 ::= INTEGER (-2147483648..2147483647)
  183.  
  184. for the definition to be valid.
  185.  
  186. The Integer32 data type was created to specify a limits for the range of
  187. signed integers.  SMIv2 allows data type INTEGER to be used if a range
  188. is specified, but requires data type Integer32 to be used if no range is
  189. specified.  However, SMIv2 restricts the range that can be specified on
  190. data type INTEGER to be identical to that for Integer32.  This duplicity
  191. for no apparent reason, is confusing to readers of MIB modules.  For
  192. this reason, the SMI should be modified so that the type INTEGER is only
  193. used for enumerated integers.
  194.  
  195.  
  196. 3.2.2 Enumerated Integers
  197.  
  198. The construct INTEGER { <listOfEnums> } is used to define a data type
  199. that represents a small list of labeled values.  This data type is
  200. called an enumerated integer.  Note that the data type starts with
  201. "INTEGER {" and not "Integer32 {".  The labeled values must be within
  202. the range allowed for data type Integer32.  The SMI specifies that only
  203. the values listed are valid for objects defined with data type of
  204. enumerated integer.
  205.  
  206. The SMI allows a textual convention to be assigned an enumerated integer
  207. data type, for example:
  208.     TcA TEXTUAL-CONVENTION
  209.         STATUS       current
  210.         DESCRIPTION  "Example TC"
  211.         SYNTAX       INTEGER { one(1), two(2), three(3) }
  212.  
  213. The SMI allows an enumerated type to be "refined", but does not
  214. explicitly specify how this is done.  For example, if a refined version
  215. of textual convention TcA were to be used in a SYNTAX clause in an
  216. OBJECT-TYPE, TEXTUAL-CONVENTION, AGENT-CAPABILITIES, or MODULE-
  217. COMPLIANCE construct, which of the following two examples are valid?
  218.  
  219.     1)  SYNTAX    TcA { one(1), three(3) }
  220.     2)  SYNTAX    INTEGER { one(1), three(3) }
  221.  
  222. The first example, while not explicitly allowed or disallowed by the SMI
  223. is not allowed by current leading MIB compilers.  The second form,
  224. unfortunately does not clearly indicate that it is refining the value of
  225. a previously defined data type.  Thus, use of a refinement of a textual
  226. convention must use the "INTEGER { . . . }" construct, and must specify
  227. in the description clause name of the textual convention being refined.
  228.  
  229.  
  230.  
  231.  
  232. Expires 1/30/1997                                               [Page 4]
  233.  
  234. Draft                      SMI Clarification               July 30, 1996
  235.  
  236.  
  237. Consider the following specific example.  A TC, called OperStatus, is
  238. created, and shown below:
  239.  
  240.     OperStatus ::= TEXTUAL-CONVENTION
  241.         STATUS      current
  242.         DESCRIPTION
  243.             "The current or desired operational state of a
  244.             sub-system.  The values are:
  245.                up(1) - ready to perform its function
  246.                down(2) - not able to perform its function
  247.                testing(3) - in some test mode and not able
  248.                   to perform its function
  249.                unknown(4) - state can not be determined
  250.                   for some reason.
  251.                dormant(5) - ready to perform its function
  252.                   after an external event occurs."
  253.         SYNTAX  INTEGER { up(1), down(2), testing(3),
  254.                           unknown(4), dormant(5) }
  255.  
  256. If refinement could be specified directly on a TC, then this TC could be
  257. used in the following constructs:
  258.  
  259.     ifAdminStatus OBJECT-TYPE
  260.         SYNTAX      OperStatus { up(1), down(2), testing(3) }
  261.        . . .  -- rest of construct
  262.  
  263.     ifOperStatus OBJECT-TYPE
  264.         SYNTAX      OperStatus
  265.        . . .  -- rest of construct
  266.  
  267.     ifCompliance MODULE-COMPLIANCE
  268.        . . .  -- clauses left out
  269.         OBJECT ifAdminStatus
  270.             SYNTAX      OperStatus { up(1), down(2) }
  271.             MIN-ACCESS  read-only
  272.             DESCRIPTION
  273.                 "Write access is not required, nor is support
  274.                 for the value testing(3)."
  275.     ::= { ifCompliances 1 }
  276.  
  277. Note that ASN.1 has the ENUMERATED type.  It is not an allowed data type
  278. in SNMP MIB modules.  Also note that the type construct "INTEGER { . . .
  279. }" in ASN.1 is used to specify distinguished values and does not limit
  280. the values.  Only an ASN.1 sub-type specification limits the range of
  281. values in INTEGER type specifications. The following type specification
  282. is valid in ASN.1 and is not valid in SNMP:
  283.     INTEGER { freezing(32), boiling(212) } (-5..450)
  284. This type specification limits values between -5 and 450 inclusive and
  285. gives names to values 32 and 212.  This can not be expressed in SNMP.
  286. The closest is the following data type specification in SNMP:
  287.     Integer32 (-5..450)
  288.  
  289.  
  290. Expires 1/30/1997                                               [Page 5]
  291.  
  292. Draft                      SMI Clarification               July 30, 1996
  293.  
  294.  
  295.  
  296.  
  297. 3.2.3 OCTET STRING
  298.  
  299. The SMI limits the maximum size of data type OCTET STRING to 65535.  No
  300. such limit exists in ASN.1.  The approach used in the SMI to specify
  301. this limitation is not valid ASN.1.  A valid approach is to create a new
  302. type, like was done with Integer32, that is a size limited version of
  303. the OCTET STRING type.  For example, the following definition could be
  304. added to the SMI:
  305.     Octets ::= OCTET STRING ((SIZE(0..65535))
  306.  
  307. With this data type defined, all uses of data type OCTET SRTING would be
  308. required to be modified to Octets (just like that which was done with
  309. INTEGER and Integer32).
  310.  
  311.  
  312. 3.2.4 OBJECT IDENTIFIER
  313.  
  314. The SMI limits the maximum values of components of a OID valid to
  315. 4294967295 and limits the maximum number of components to 128.  (The SMI
  316. calls components, sub-identifiers, a term not used in ASN.1.)  ASN.1 has
  317. no limit on the maximum number of components in an OID value. Also,
  318. there is no maximum for component values. (Note that ASN.1 (and the SMI)
  319. require that OID values have at least two components. The first value of
  320. the first component may be 0, 1, or 2.  The value of the second
  321. component is limited to 39 if the first component has value 0 or 1.) The
  322. approach used in the SMI to specify the limitations on OID values is
  323. incorrect.  A valid approach is to create a new type, like was done with
  324. Integer32, that has its length and values of components limited, which
  325. is based on the OBJECT IDENTIFIER type.  For example, the following
  326. definition could be added to the SMI:
  327.     OID ::= -- the maximum number of components is limited to 128 and
  328.             -- the maximum value of a component is limited to 4294967295
  329.             OBJECT IDENTIFIER
  330.  
  331. With this data type defined, all uses of data type OBJECT IDENTIFIER
  332. would be required to be modified to OID (just like that which was done
  333. with INTEGER and Integer32).
  334.  
  335.  
  336. 3.2.5 Opaque
  337.  
  338. The Opaque data type is not size limited.  This appears to be an over
  339. site.  This could be corrected by replacing:
  340.     Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING
  341. with the following definition:
  342.     Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING(SIZE(0..65535))
  343.  
  344. A full description of the Opaque data type, which has been generally
  345. misunderstood by the SNMP community, is not included in the SMI.  A full
  346.  
  347.  
  348. Expires 1/30/1997                                               [Page 6]
  349.  
  350. Draft                      SMI Clarification               July 30, 1996
  351.  
  352.  
  353. explanation is specified in "The Domestication of the Opaque Type for
  354. SNMPv1 and SNMPv2"[6].
  355.  
  356.  
  357. 4. Syntax of the MIB Module Language
  358.  
  359. The SMI assumes that its readers are versed in the ASN.1 language, and
  360. thus omits important details describing the MIB module language.  This
  361. assumption has been shown to be problematic by the variations observed
  362. in programs, called MIB compilers, which parse MIB modules.  This is
  363. also shown by the recurring questions about the syntax of MIB modules
  364. that come up on the SNMP and SNMPv2 mailing lists, and the SNMP news
  365. group.  One of the reasons why this has been so difficult for compiler
  366. writers is that the terms that are used in the SMI for elements of the
  367. MIB module language are different than that used for the same elements
  368. in the ASN.1 language.
  369.  
  370. Traditionally, the syntax of a language is specified by the definition
  371. of the elementary items, or tokens, of the language, a grammar for the
  372. syntax, and text specifying the rules for valid passages of the
  373. language.  Usually, parsers of a language have three functional areas.
  374. The first area performs lexical analysis of its input, which is usually
  375. a sequence of characters in a specified character set.  The output from
  376. this functional area is a sequence of tokens.  The next functional area
  377. reads the sequence of tokens to determine if they conform to the grammar
  378. of the language.  The final functional area of a parser evaluates the
  379. statements in the input to determine if the passage (or program) is
  380. valid.
  381.  
  382. Consider the following assignment statement in the C programming
  383. language:
  384.     a = b;
  385.  
  386. The lexical definition of the C programming language specifies rules for
  387. tokens in the language.  The lexical analyzer would input the sequence
  388. of characters in the line and output the following tokens:
  389.     identifier - value "a"
  390.     punctuation - value "="
  391.     identifier - value "b"
  392.     punctuation - value ";"
  393.  
  394. The syntax analyzer would input the sequence of tokens and determine
  395. that they represented an assignment statement of the language.  The
  396. semantic analyzer would then determine if the assignment statement was
  397. valid using rules such as are variables "a" and "b" known in the scope
  398. of the assignment statement, and are the data types for the variables
  399. compatible for assignment.
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406. Expires 1/30/1997                                               [Page 7]
  407.  
  408. Draft                      SMI Clarification               July 30, 1996
  409.  
  410.  
  411. 4.1 Lexical Specification
  412.  
  413. The lexical elements of the MIB module language are specified by section
  414. 8 of the ASN.1 specification[4], augmented by the ASN.1 macros defined
  415. for the MIB module language, and modified by textual descriptions in
  416. SMIv2[1][2][3].  Also, there are standard practices found in most of the
  417. leading MIB compilers that are accepted by the SNMP community as part of
  418. the MIB module language.  There has been no one place that integrates
  419. these into one coherent definition.  This is now specified in "A Lexical
  420. Specification for the SNMPv2 MIB Module Language"[7], which also
  421. includes a Lex specification for the tokens of the language. (Lex is a
  422. widely used program to generate lexical analyzers.)
  423.  
  424.  
  425. 4.2 Grammar Specification
  426.  
  427. The grammar for the MIB module language is specified by the ASN.1
  428. specification[4], augmented by the ASN.1 macros defined for the MIB
  429. module language, and modified by textual descriptions in SMIv2[1][2][3].
  430. Also, there are standard practices found in most of the leading MIB
  431. compilers that are accepted by the SNMP community as part of the MIB
  432. module language.  There has been no one place that integrates these into
  433. one coherent definition.  This is now specified in "A Grammar
  434. Specification for the SNMPv2 MIB Module Language"[8].  A grammar is
  435. presented in the form of extended BNF and also in the form of input for
  436. Yacc.  (Yacc is a widely used program to generate parsers.)
  437.  
  438.  
  439. 4.3 Semantic Specifications
  440.  
  441. The rules to determine if a MIB module is valid and the meaning of a MIB
  442. module are written in textual descriptions in SMIv2[1][2][3], and
  443. supported by the ASN.1 language[4].  Only a few MIB compilers perform
  444. more than trivial checking, and none check all the rules.  There is only
  445. one known compiler that attempts complete checking.  Also, there is much
  446. disagreement in the SNMP community over many issues in this area.  What
  447. follows is in the format of topic and clarifying information.
  448.  
  449.  
  450.  
  451. 4.3.1 Prime Directive of MIB Module Design
  452.  
  453. Once definitions have been published, they can not be semantically
  454. changed, or deleted.  Definitions that were flawed or are no longer
  455. useful may be retired by changing the value of their status to
  456. "obsolete".  New definitions can be added to MIB modules.
  457.  
  458. This is the most important rule for MIB module design and maintenance.
  459. Breaking it (or making exceptions for short term gain) should be
  460. avoided.
  461.  
  462.  
  463.  
  464. Expires 1/30/1997                                               [Page 8]
  465.  
  466. Draft                      SMI Clarification               July 30, 1996
  467.  
  468.  
  469. 4.3.2 Format of Tokens in a MIB Module
  470.  
  471. The tokens in a MIB module have no requirement to be on the same or
  472. different lines.  Any requirements or restrictions in this area are
  473. those imposed by a non-compliant MIB parser.
  474.  
  475.  
  476. 4.3.3 Location of MODULE-IDENTITY Construct
  477.  
  478. All MIB modules must include exactly one MODULE-IDENTITY construct which
  479. is located after the IMPORTS statement, and before any other construct
  480. in the MIB module. (Note that comments function as "white space" and
  481. thus may be specified before the MODULE-IDENTITY construct.)
  482.  
  483.  
  484. 4.3.4 Ordering of Constructs in a MIB Module
  485.  
  486. The constructs in a MIB module, other than IMPORTS and MODULE-IDENTITY,
  487. may be specified in any order.  This may result in a construct using an
  488. item which is defined later in the MIB module.  For example, the OID
  489. value specified for the MODULE-IDENTITY may reference an OID value which
  490. is defined later in a MIB module.
  491.  
  492.  
  493. 4.3.5 Registration and Assignment of OID Values
  494.  
  495. The ASN.1 language has no direct mechanism to register an OID value to
  496. an item.  Registration is accomplished in ASN.1 through processes
  497. outside of ASN.1 modules.  Registration is the permanent assignment of
  498. an OID value to an item.  After a valid registration, the OID value can
  499. not be registered to another item for all time; the assignment is
  500. remembered for all time; and the semantics of the item can not be
  501. changed for all time.  Given the OID value, the item (after
  502. registration) can be positively identified, for all time.  The MIB
  503. module language contains constructs which are used to perform
  504. registration.  These constructs are OBJECT-TYPE, MODULE-IDENTITY,
  505. OBJECT-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP, NOTIFICATION-GROUP,
  506. MODULE-COMPLIANCE, and AGENT-CAPABILITIES.  A item defined with one of
  507. these constructs is permanently assigned the OID value specified in that
  508. construct.  That OID value can not be used for any other permanent
  509. assignment - a registration.  However, the OID value assignment
  510. construct is not a permanent assignment.  Below is an example of an OID
  511. value assignment:
  512.         system OBJECT IDENTIFIER ::= { mib 1 }
  513.  
  514. This value assignment in a MIB module is not a registration.  It is a
  515. convenience for the MIB designer to write the value { mib 1 }.  Without
  516. such a shorthand mechanism, an OID value would need to be completely
  517. specified from the root or from an item with a permanently assigned OID
  518. value.  For example, the OID value used in the OBJECT-TYPE construct for
  519.  
  520.  
  521.  
  522. Expires 1/30/1997                                               [Page 9]
  523.  
  524. Draft                      SMI Clarification               July 30, 1996
  525.  
  526.  
  527. sysDescr would be specified as { iso 3 6 1 2 1 1 1 } instead of { system
  528. 1 }.
  529.  
  530. Note that it is valid in ASN.1 to write a module that contains more than
  531. one OID value assignment with the same OID value.  This is shown below:
  532.         v1 OBJECT IDENTIFIER ::= { mib 1 }
  533.         v2 OBJECT IDENTIFIER ::= { mib 1 }
  534.  
  535. The SNMPv2 SMI is completely silent on this and related issues. For
  536. example, can a MIB module contain an OID value assignment and a
  537. registration with the same OID value?  This shown below:
  538.         s1 OBJECT IDENTIFIER ::= { system 1 }
  539.         sysDescr OBJECT-TYPE
  540.            -- clauses (omitted)
  541.             ::= { system 1 }
  542.  
  543. The proper behavior is not well defined.
  544.  
  545.  
  546. 4.3.6 OID Values to Identify Modules
  547.  
  548. <describe this - ASN.1 vs. MODULE-IDENTITY>
  549.  
  550.  
  551. 4.3.7 Module Names and OID Values in IMPORTS Statement
  552.  
  553. <describe why and how and OID value is used to identify a MIB module in
  554. an IMPORTS>
  555.  
  556.  
  557.  
  558. 4.3.8 Well Known Names in an OID Value
  559.  
  560. The nodes at the top of the OID value tree were assigned "well known"
  561. names by ISO and CCITT.  ASN.1 compilers are expected to know these
  562. names.  However, the list of names has expanded, and was changed when
  563. the CCITT changed its name to ITU.  This is disruptive to MIB designers,
  564. users, and compiler writers.  Thus, in the MIB module language, the only
  565. well known names are ccitt, iso, and joint-iso-ccitt.  These names will
  566. never be changed, or will new names added, since this is not installed
  567. base friendly.
  568.  
  569.  
  570. 4.3.9 Max Length of MIB Module Names
  571.  
  572. The SMI doesn't specify a max length. It should.
  573.  
  574.  
  575.  
  576.  
  577.  
  578.  
  579.  
  580. Expires 1/30/1997                                              [Page 10]
  581.  
  582. Draft                      SMI Clarification               July 30, 1996
  583.  
  584.  
  585. 4.3.10 Required Constructs in a MIB Module
  586.  
  587. Every MIB module must include an IMPORTS and a MODULE-IDENTITY
  588. statement.
  589.  
  590.  
  591. 4.3.11 Meaning of the Values of the STATUS Clause
  592.  
  593. The meaning of the values of the STATUS clause are not well defined in
  594. SMIv2.  The memo "A Clarification of the STATUS Clause in SNMP MIB
  595. Modules"[9] contains what the values mean, and what actions agent and
  596. management applications developers should take based on the value, and
  597. change of value.
  598.  
  599.  
  600. 4.3.12 The Value of the CONTACT-INFO Clause
  601.  
  602. The examples given in the SMI for the values of the CONTACT-INFO clause
  603. of MODULE-IDENTITY in SMIv2 should not be used.  Other information such
  604. as the working group name and mailing list need to be specified.
  605.  
  606.  
  607. 4.3.13 Objects in the INDEX Clause
  608.  
  609. (This needs to be determined)
  610.  
  611.  
  612. 4.3.14 Consistency of Status Values
  613.  
  614. Several constructs are dependent of the definitions of other items.  For
  615. example, the INDEX clause in the OBJECT-TYPE construct names other
  616. items.  Another example is a table object and the columnar objects with
  617. in the table.  The SMI is silent on the relationships between the status
  618. of these objects.  Thus, could the status of a row object be "current"
  619. if one of the objects in its INDEX clause has the status of "obsolete"?
  620. If a table object has its status changed to "obsolete", do all of the
  621. columnar objects in the table have to also have to have their status
  622. changed to "obsolete"?  This issue needs to be resolved.
  623.  
  624.  
  625. 4.3.15 Module Compliances and Agent Capabilities
  626.  
  627. (Some major work needed here - probably separate documents)
  628.  
  629.  
  630. 5. Relationships Between Objects
  631.  
  632. (There needs to be a section or maybe another document about
  633. relationships between objects.  This section needs to specify whether or
  634. not the RMON2 approach to indexing was valid or invalid, and give rules
  635. for how it should be used.)
  636.  
  637.  
  638. Expires 1/30/1997                                              [Page 11]
  639.  
  640. Draft                      SMI Clarification               July 30, 1996
  641.  
  642.  
  643.  
  644.  
  645. 6. References
  646.  
  647. [1]  J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Structure of
  648.      Management Information for Version 2 of the Simple Network
  649.      Management Protocol (SNMPv2)", RFC 1902, 01/22/1996.
  650.  
  651. [2]  J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Textual
  652.      Conventions for Version 2 of the Simple Network Management Protocol
  653.      (SNMPv2)", RFC 1903, 01/22/1996.
  654.  
  655. [3]  J. Case, K. McCloghrie, M. Rose, S. Waldbusser, "Conformance
  656.      Statements for Version 2 of the Simple Network Management Protocol
  657.      (SNMPv2)", RFC 1904, 01/22/1996.
  658.      Management Information for version 2 of the Simple Network
  659.      Management Protocol (SNMPv2)", RFC 1442, 05/03/1993.
  660.  
  661. [4]  Information processing systems - Open Systems Interconnection -
  662.      Specification of Abstract Syntax Notation One (ASN.1),
  663.      International Organization for Standardization.  International
  664.      Standard 8824, (December, 1987).
  665.  
  666. [5]  D. Perkins, "The BITS Pseudo-type for SNMPv2 SMI", internet-draft
  667.      draft-perkins-bits-00.txt, 05/27/1996.
  668.  
  669. [6]  D. Perkins, "The Domestication of the Opaque Type for SNMPv1
  670.      and SNMPv2", internet-draft draft-perkins-opaque-00.txt,
  671.      05/27/1996.
  672.  
  673. [7]  D. Perkins, "A Lexical Specification for the SNMPv2 MIB Module
  674.      Language", (yet to be posted internet-draft).
  675.  
  676. [8]  D. Perkins, "A Grammar Specification for the SNMPv2 MIB Module
  677.      Language", (yet to be posted internet-draft).
  678.  
  679. [9]  D. Perkins, "A Clarification of the STATUS Clause in SNMP MIB
  680.      Modules", internet-draft draft-rfced-info-perkins-01.txt
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696. Expires 1/30/1997                                              [Page 12]
  697. -----------------
  698.  
  699. /dperkins@scruznet.com, David T. Perkins
  700. Date: 07/30/96, Time: 09:11:35
  701.  
  702.  
  703.