The meaning of the status values is as follows:

• submitted means that the issue was submitted but no decision has been made whether the problem is within scope.
• accepted means that the problem was accepted to be within the scope. Note that this applies only to the problem description and the solution might be completely different than the proposed solution.
• rejected means that the problem was reject as being out of scope.

From: daniele@zk3.dec.com
Status: accepted

The definition of the DateAndTime TC should state that the year is represented in network-byte order. RFC 1903 says on page 20 that numbers are interpreted to be in network-byte order when displaying them using the `x', `d' or `o' formats. However, agent implementors tend to not read about DISPLAY-HINTs and the formatting rules. A clarification in the description of the TC that the year is represented in network-byte order will help to avoid problems.

From: rfrye@MCI.NET
Status: accepted

There is confusion whether BITS needs to be imported or not. A discussion on the SNMPv3 mailing list led to the conclusion that the correct answer is "not". This should be clarified in an update of RFC 1902.

From: dperkins@dsperkins.com
Status: rejected

ASN.1 and the SMI allow use of references to imported items in a MIB module as <Module-name>"."<item>. This syntax is only supported in a single MIB compiler. Other MIB compilers do not accept such syntax. Such syntax either needs to be disallowed (because there are not two interoperable implementations) or text added to clarify the required support of it in MIB compilers conforming to the SMI.

MIB modules that demonstrate this issue:
SITESTROOT-MIB SITEST7-MIB SITEST8-MIB

From: dperkins@dsperkins.com
Status: accepted

SMIv2 went too far in its restriction of ASN.1 rules for forming identifiers by adding the restriction that hyphens cannot be used in the identifiers for SNMP descriptors or labels for enumerations or BITS. There is little demonstrated benefit and much demonstrated pain in this restriction. Also it is confusing, since module names are allowed to contain hyphens and hyphens are allowed in other lexical items of the language. (Also, there are SMIv2 MIB modules on the standards track that contain hyphens in descriptors.) The pain shows itself when MIBs in SMIv1 are converted to SMIv2 format. (There are many MIB modules in the SMIv1 format.) I suggest that we remove this restriction from SMIv2.

MIB modules that demonstrate this issue:
SITESTROOT-MIB SITEST4-MIB

From: schoenw@ibr.cs.tu-bs.de
Status: rejected

The existing SMIv2 documents RFC 1902, RFC 1903 and RFC 1904 should be merged into a single document. This reduces the confusion of what is part of the SMIv2 and not and it also reduces the total number of SNMP core specifications.

From: schoenw@ibr.cs.tu-bs.de
Status: submitted

The agent capabilities have seen little usage. Agent capability definitions are not generally available and there are to my knowledge no management applications that take advantage of agent capability definitions. The reported usage of agent capability statements is for internal implementation status management. It is therefore questionable whether agent capabilities qualify for full standard status.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

The description in RFC 1902 is vague about the values allowed in DEFVAL clauses. For example, it is not clear that an empty set is represented as DEFVAL { {} }.

From: schoenw@ibr.cs.tu-bs.de,rpresuhn@bmc.com
Status: accepted

RFC 1903 section 3.5 does not allow the subtyping of TCs. This is however used in MIB modules. A clear decision must be made and documented in the SMIv2 specs that either these MIB modules are broken or the conditions under which sub-typing is allowed have to specified and the semantics associated with it.

Currently, RFC 1902 and 1903 are at odds with each other with respect to the question of whether a TC may be subtyped. I would prefer that the current language in RFC 1902 prevailed:

|13.3.  Rules for Textual Conventions
|
|   Sub-typing of Textual Conventions (see [3]) is allowed but must be
|   valid.  In particular, each range specified for the textual
|   convention must be a subset of a range specified for the base type.

See also draft-perkins-clartc-00.txt.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

Reverse mappable notifications are desirable in many cases. Text should be added to the SMIv2 which discusses the issue and suggests that MIB designers define reverse mappable notifications unless there are good reasons not to do so.

From: schoenw@ibr.cs.tu-bs.de,rpresuhn@bmc.com
Status: accepted

RFC 1902 section 7.1.6 says that a discontinuity indicator for a Counter32 object should be a TimeStamp object. It is unclear whether it is allowed to use other discontinuity indicators as well, e.g. objects of type DateAndTime.

In the course of work on several MIBs, many of us have found the RFC 1902 clause 7.1.6 and 7.1.10 language on discontinuity indicators to be overly restrictive. For many environments, particularly where SNMP is being used for application or service management, permitting DateAndTime (as an alternative to TimeStamp) for discontinuity indicators would be valuable.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

The transition active -> notInService only allows a wrongValue error (RFC 1905, section "Conceptual Row Suspension"). However, there are situations where an inconsistentValue error would be more appropriate because the value might be valid at a later point in time.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

The DISPLAY-HINT format specifier 'a' is used to display an octet as an ASCII character. This format specifier is also used for UTF8 character sets (because there is no UTF8 format specifier). It must be clarified whether the 'a' format specifier also works with UTF8 characters. It is also unclear how the octet length notation interacts with multiple byte UTF8 characters.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

Section 3.1 in RFC 1903 says that the DISPLAY-HINT clause may be present if and only if the syntax has an underlying primitive type of INTEGER or OCTET STRING. It also says that it does not make sense to use it with e.g. Counter32. This text leaves it to the implementor to decide which SMI base types are allowed and which not. The text should be changed to list those SMIv2 base types that are allowed.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

The application of a `b', `x' or `o' format specifier on a negative number is not well defined. How is the number represented and what is the size of the negative extension? Is it safe to assume a 32bit signed integer value? Does a SIZE restriction have any influence on the result?

From: rpresuhn@bmc.com
Status: accepted

Despite the fact that the unfortunate word "latch" never appears in RFC 1902, and despite the explicit language to the contrary in RFC 1902 clause 7.1.7, the myth that gauges somehow get "stuck" if they ever reach their maximum value seems to persist.

From: rpresuhn@bmc.com
Status: accepted

Can the syntax for the MODULE-IDENTITY macro be extended to permit GeneralizedTime (with reasonable constraints) in addition to the current UTCTime, in order to address millenium issues with the LAST-UPDATED clause?

From: rpresuhn@bmc.com
Status: rejected

The SMI current (in the form of an ASN.1 comment) limits DESCRIPTION clauses to NVT ASCII. Can this be clarified to permit UTF-8?

From: rpresuhn@bmc.com
Status: accepted

If a sysUpTime.0 discontinuity occurs, does this in any way affect MIB objects of syntax TimeStamp whose non-zero values were established prior to the discontinuity? I hope the answer is no, but I've heard other interpretations.

From: rpresuhn@bmc.com
Status: accepted

RFC 1902 says:

|7.6.  Mapping of the REFERENCE clause
|
|   The REFERENCE clause, which need not be present, contains a textual
|   cross-reference to an object defined in some other information
|   module.  This is useful when de-osifying a MIB module produced by
|   some other organization.

and

|8.4.  Mapping of the REFERENCE clause
|
|   The REFERENCE clause, which need not be present, contains a textual
|   cross-reference to a notification defined in some other information
|   module.  This is useful when de-osifying a MIB module produced by
|   some other organization.

It seems that this is commonly applied in a far less strict manner as a means of providing pointers to relevant references, rather than to actual definitions of management information.

Change: make it clear(er) how this clause is to be used.

From: scheng@mas.co.nz
Status: rejected

In the course of writing textual conventions, I have come across many instances when I wish the UNITS clause is allowed in a TEXTUAL-CONVENTION macro.

From: rpresuhn@bmc.com
Status: accepted

Yet another RFC 1902 point of unclarity. Imagine a NOTIFICATION-TYPE that reports, for example, the failure of a relationship between two objects of the same type. One would like to send out a TRAP identifying both object instances. In writing the NOTIFICATION-TYPE, should one:

1. not list the OBJECT-TYPE in the OBJECTS clause, relying solely on the DESCRIPTION to say that multiple instances may appear in the varbind list;
2. list the OBJECT-TYPE once in the OBJECTS clause, relying solely on the DESCRIPTION to say that multiple instances may appear in the varbind list;
3. list the OBJECT-TYPE twice in the OBJECTS clause, relying on the DESCRIPTION to say what instances would appear in the varbind list.

From: Olivier.Miakinen@bull.net
Status: accepted

RFC 1902 (7.1.12) states that the <syntax> has the value of the subordinate object's SYNTAX clause, "normally omitting the sub-typing information". An example of that is in RFC 1907:

| SysOREntry ::= SEQUENCE {
|     sysORIndex     INTEGER,
|     sysORID        OBJECT IDENTIFIER,
|     sysORDescr     DisplayString,
|     sysORUpTime    TimeStamp
| }

I think that several points need clarification:

1. Is it allowed that one doesn't omit the sub-typing information ? For instance:

   |     sysORIndex     INTEGER (1..2147483647),
   

2. Is it allowed that one uses the "basic type" ? For instance:

   |     sysORDescr     OCTET STRING,
   

3. When the SYNTAX clause was a BITS, and since BITS is a parameter of the macro OBJECT-TYPE (and not an ASN.1 type), should one replace the BITS with OCTET STRING in the SEQUENCE { ... } ?
   Note: I suppose so, but existing mibs seem to prefer to use BITS instead of OCTET STRING.

From: Olivier.Miakinen@bull.net
Status: accepted

In RFC 1902, section 9 (Refined Syntax), the list of allowed refinements for OCTET STRING are `size' and `repertoire'. I frequently saw refinements on size, e.g. OCTET STRING (SIZE (0..255)). But never refinements on repertoire, e.g. OCTET STRING (FROM ("0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"))

Are they actually allowed ? How many MIB compilers can accept them ?

From: gary@kentrox.com
Status: accepted

Unlike its predecessor (RFC 1442) and its companions (RFC 1903 and RFC 1904) RFC 1902 lacks a Table of Contents section. One should be added in an RFC 1902 successor.

From: gary@kentrox.com
Status: rejected

RFC 1902 and RFC 1904 both use the term "non-editorial" without defining the extent of what is considered "editorial". Since this is done in reference to what changes can and cannot be done to object assignments, object definitions, notification definitions, object groups, compliance definitions, and capabilities definitions, WITHOUT having to change the associated OBJECT IDENTIFIER value and descriptor, the term should be clarified in successors to these documents.

For example, section 10.2 of RFC 1902 does not permit the revision of a DESCRIPTION clause for an object, other than when changing the value of its STATUS clause, or when making non-editorial changes, and states that in other cases the OBJECT IDENTIFIER value must be changed. However, some MIB-II objects have in fact had their DESCRIPTION changed without reassigning OBJECT IDENTIFIER values, and in some cases the changes COULD be argued to go beyond "editorial" (e.g., sysDescr, sysContact/Name/Location, ifIndex, ifType, ifSpeed, ifPhysAddress, ifInOctets/InUcastPkts/etc., etc.). Similar changes have been seen for objects in internet-drafts that contain revisions to existing proposed standard MIBs.

Since most of these revisions were allowed on a case-by-case basis in order to either (a) let an object's DESCRIPTION match existing implementations that had deviated from the original intent, or (b) to accommodate new and unforeseen situations that have arisen subsequent to the original definition of the object, it would be helpful to identify that changes made in these situations can be considered "non-editorial" for the purposes of these documents.

From: gary@kentrox.com
Status: accepted

RFC 1903 does not discuss whether changes are legally allowed to TEXTUAL-CONVENTION macros, nor how to accommodate the ambiguity that such changes might lead to if they are allowed.

One could assume, based on RFC 1902 sections 7.1 and 10.2, that such changes are NOT allowed, since it would result in a change to the SYNTAX of an object. However, a number of changes have been allowed which appear editorial (e.g., InterfaceIndex, RowStatus), and it is important to ensure that such changes are documented to be legal.

Some statement about allowing "editorial" changes would be helpful, along with a statement about what would be considered to be "non-editorial". (Note that this is similar to the issue about the definition of "non-editorial" in RFC 1902 and RFC 1904.)

Some statement about dealing with ambiguities that may arise would also be helpful, although it is not clear (to me) what definitively could be said about how to deal with them.

From: Olivier.Miakinen@bull.net
Status: accepted

In ASN.1 (ISO/IEC 8824-1), an hexadecimal string shall not contain any lower case character, and it ends with 'H (upper case H). Similarly, a binary string ends with 'B (upper case B).

Now examples of hexadecimal strings for DEFVAL in RFC 1902 have lower case characters within the '' but un upper case H at the end: 'ffffffffffff'H or 'c0210415'H.

I think the new RFC should state if:

• upper case characters are allowed within the ''
• an hexadecimal string can end with 'h
• a binary string ends with 'B or 'b or either of them

I mean, is each following DEFVAL allowed ?

1) DEFVAL { 'ff'h }  -- lower case h
2) DEFVAL { 'FF'H }  -- upper case within the ''
3) DEFVAL { 'Ff'H }  -- mixed cases within the ''
4) DEFVAL { '01'b }  -- lower case b
5) DEFVAL { '01'B }  -- upper case B

Note that, in pure ASN.1, only examples (2) and (5) are allowed.

From: Olivier.Miakinen@bull.net
Status: rejected

ASN.1 definition states for binary and hexadecimal strings that "white-space and newlines have no significance", e.g. the two following hexadecimal strings are equivalent:

'AB0196'H

and:

'AB 019
   6 'H

Is it also true for SMIv2 DEFVAL ?

From: johnf@hprnljf.rose.hp.com
Status: rejected

A problem I have run into has to do with the following paragraph in section 3 of RFC 1902:

   All information modules start with exactly one invocation of the
   MODULE-IDENTITY macro, which provides contact information as well as
   revision history to distinguish between versions of the same
   information module.  This invocation must appear immediately after
   any IMPORTs statements.

The problem arises when one needs to provide the path to the OID value of the MODULE-IDENTITY. One example of this is found in the repeater MIB:

   IMPORTS
       Counter32, Counter64, Integer32, Gauge32, TimeTicks,
       OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, mib-2
           FROM SNMPv2-SMI
...
 
   snmpRptrMod MODULE-IDENTITY
...
          ::= { snmpDot3RptrMgt 5 }
 
   snmpDot3RptrMgt OBJECT IDENTIFIER ::= { mib-2 22 }

The rules in 1902 pretty much require a forward reference to define the OID for the MODULE-IDENTITY. Many popular MIB compilers in use today are 1 pass compilers and cannot handle a forward reference. There appear to be only two ways to satisfy most MIB compilers:

1. define another MIB module, whose sole purpose is to define snmpDot3RptrMgt, so that the repeater MIB can import it
2. ignore the rules, and move the assignement of snmpDot3RptrMgt above the MODULE-IDENTITY macro (only 1 compiler complains about this - guess which one).

Personally, I would like to see the updated SMI allow the second option.

Randy suggested some other options for dealing with this that also seemed to cause problems. Defining snmpRptrMod as { mib-2 22 5 } or { mib-2 snmpDot3RptrMgt(22) 5 } are also known to not work with many compilers. I also saw compilers that do allow the second form have different interpretations of it. It is not clear whether the definition of snmpDot3RptrMgt in that OID value is local to that definition or global within the module. In other words, the following set of definitions:

   snmpRptrMod MODULE-IDENTITY
...
          ::= { mib-2 snmpDot3RptrMgt(22) 5 }
 
   snmpDot3RptrMgt OBJECT IDENTIFIER ::= { mib-2 22 }

caused one compiler to complain about a redefinition of snmpDot3RptrMgt, where as omitting the separate definition of snmpDot3RptrMgt caused other compilers to complain that snmpDot3RptrMgt was undefined when used in later definitons.

From: dperkins@dsperkins.com
Status: accepted

The max-access value "accessible-for-notify" is not well understood as to when it can be used. Some say that it is only for the special objects snmpTrapOID and snmpTrapEnterprise. Others say any objects can be defined with that access. The rules need to be clarifified.

A big factor is that event reporting (even with INFORMS) is not 100% reliable. A manager must be able to determine that events have occured without receiving an event report by polling. If there is information that is needed that cannot be retrieved with GET/GETNEXT/GETBULK, then a manager cannot function without event reports.

From: heard@vvnet.com
Status: submitted

Here is another proposed RFC 1902 update: revise the language of Section 7.1.9 to permit future standards-track efforts to use the Opaque data type to extend the base set of data types. The recommended replacement text is as follows:

   The Opaque data type supports the capability to pass arbitrary ASN.1
   syntax.  A value is encoded using the ASN.1 Basic Encoding Rules
   into a string of octets.  This, in turn, is encoded as an OCTET
   STRING, in effect "double-wrapping" the original ASN.1 value.
 
   An implementation conforming to this specification must be able to
   accept and recognize opaquely-encoded data.
 
   Although this specification does not require that an implementation be
   able to unwrap opaquely-encoded data and then interpret its contents,
   future standards-track specifications may define such requirements.
   Standard-tracks MIB modules shall not, however, define objects with a
   SYNTAX clause value of Opaque in the absence of such specifications.

RATIONALE: Requirements have arisen in both IETF standards-track efforts and elsewhere for at least one data type (Unsigned64) with semantics not provided for in the current SMIv2 specification. It is not unreasonable to expect that other requirements will arise in the future. As the SMI document is presently written, it is not possible to define data types with new (as opposed to refined) semantics without recycling the SMI back to Proposed Standard. Furthermore, adding new application tags will create backward compatibility problems with deployed implementations because the existing protocol specification requires that unknown tags be treated as parse errors, resulting in packets being silently dropped. The result is that when the need for a new data type arises, people are tempted to use an existing data type in a manner inconsistent with its specification. This is not a good situation.

The goal of this proposal is to allow future standards-track specifications to use the Opaque type to define new data types without modifying the base SMI document and to do so in a way which does not force a parse error in an implementation which does not recognize the new type. It is envisaged that a framework document would specify a set of grould rules along the lines of what is proposed in section 5 of David Perkins's I-D "The Domestication of the Opaque Type for SNMP" (draft-perkins-opaque-01.txt, 6/7/97; a URL is ftp://ftp.snmpinfo.com/smi-clarification/draft-perkins-opaque-01.txt). Data type specification documents would follow along the lines of draft-perkins-bigint-00.txt and draft-perkins-float-00.txt (both of these are available from the ftp site previously cited). Standards-track MIB modules would make use of the Opaque type only in this manner, and new data types would be added only when consensus exists that there is a demonstrated need.

From: dperkins@dsperkins.com
Status: accepted

The area that causes the most problems in writing MIB module is getting the IMPORTS correct. A large part of the problem is because SMI types and constructs must be imported before use, but ASN.1 types and constructs may not be imported. These requirements seem completely arbitary to MIB authors. (This problem is made more pronounced because some MIB compilers check imports and some do not.) These requirements are in place because of the boot strapping of the MIB module language from the ASN.1 language. Today, the one real purpose that imports of data types and language constructs serve is to let MIB compilers that support both SMIv1 and SMIv2 know if the module being processed is in the SMIv1 or SMIv2 MIB module language!

I suggest that the imports of the SMI data types and constructs be made optional in the current version of the SMI, and removed in future versions of the SMI! The only imports that would be needed in a MIB module are those for items defined in other MIB modules and not for constructs and data types of the MIB module language. (There would still be needed imports of well known textual conventions (such as DisplayString) and items with OID values, such as "enterprises".)

From: dperkins@dsperkins.com
Status: rejected

Many MIB compilers do not check module compliance, object group, notification group, or agent capabilities constructs for validity. (They may "parse over" them, but do not check them.)

I suggest that the SMI specify two or three levels (and/or types) of MIB compiler compliance. For example, a MIB compiler that can parse all constructs but can verify completely only OBJECT-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, TEXTUAL-CONVENTION, OID value assignment, type assignment, and SEQUENCE constructs, and can verify only OID value usage in MODULE-IDENTITY, OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE, and AGENT-CAPABILITIES constructs is labeled as a BASIC conformant MIB compiler. A MIB compiler that can parse and verify all constructs is labeled as a FULL conformant MIB compiler. A MIB compiler that can verify that changes between sets of MIB modules are valid is called VERIFICATION conformant MIB compiler.

From: dperkins@dsperkins.com
Status: rejected

The ASN.1 specification does not define practical issues found in other computer language definitions, and the SMI does not provide clarification.

Some terminology needs to be defined and minimum requirements specified for conforming processors of the MIB module language.

First, a name needs to be given to a file that contains one or more MIB modules. Suggestion - such a file is called a "MIB module file" or a "MIB file".

Secondly, there is no specification in the SMI as to whether a MIB file can contain exactly one, or several MIB modules. Suggestion - allow a MIB file to contain one or more MIB modules.

Thirdly, a name needs to be given to computer programs that parse MIB files and determine if they are valid or not valid. Suggestion - call such a program a MIB compiler.

Fourthly, there is no statement whether MIB compilers are required to process MIB files containing more than one MIB module and/or if they are required to process more than one MIB file as input. Suggestion - minimum requirement is that a conformant MIB compiler process a single MIB module for MIB file, and need only process a single input MIB file. However, because MIB modules can reference other MIB modules via IMPORTS specifications, then a compliant MIB compiler must be able to resolve such references via implementation mechanisms.

Fifthly, MIB modules are typically contained in RFCs, which contain text other than MIB modules and headers, footer, page breaks, etc. Is a conforming MIB compiler required to extract MIB modules from such documents? Suggestion - there is no requirement for a compliant MIB compiler to extract MIB module(s) from text documents. (The extracting process is an off-line operation that may be done with a program or text editor.)

Sixthly, there is no statement as to the required output of a MIB compiler. Suggestion - a conforming implementation of a MIB compiler must specify if the input MIB module or modules are valid or not valid. A conforming MIB compiler is not required to generate any other outputs such as a list of items with OID values defined in the input set of MIB modules or a list of items with types defined in the input set of MIB modules. A MIB compiler is not conformant if it does not have a mechanism to turn off allowed extentions to the MIB module language or a relaxation of validity checking. For example, if a MIB compiler allowed erroneous inputs to be accepted because it chooses not to check certain constructs such as AGENT-CAPABILITIES, then the MIB compiler is not conformant. A MIB compiler (which may be a set of programs) is not conformant if it does not verify that the items specified in an IMPORTS construct exist and are used properly.

From: dperkins@dsperkins.com
Status: rejected

The ASN.1 specification does not specify requirements of line sizes, the requirements for MIB file size, the end of line terminators, or the character sets in MIB files.

Suggestions for conformant MIB compilers:

1) the minimum maximal size of a line must be 255 characters, excluding the line terminator. Longer line lengths may be supported.

2) the minimal maximal number of lines in a MIB file must be 65535. MIB files with a greater number of lines may be supported.

3) the 7-bit ASCII character set must be supported. Additional character sets may also be supported.

4) a line terminator of a single ASCII "nl" character (hex value '0a'h), or the pair of ASCII characters "cr" and "nl" (hex values '0d'h and '0a'h) must be supported with the ASCII character set. Additional line terminators may be supported. (NOTE: the definition of line terminators must be specified because the definition of a comment says that a comment is ended by a line terminator.)

From: dperkins@dsperkins.com
Status: rejected

A clear and concise definition is needed of the allowed characters in MIB module files.

Suggestion:

There are two classes of characters in MIB module files -- the "normal" ones and the "additional" ones. The "normal" ones are those in tokens other than strings, and the "white space" characters. The additional ones are displayable characters that may be specified in strings and in comments. The "normal" ones are:

     A-Z the uppercase letters
     a-z the lowercase letters
     0-9 the decimal digits
     { left curly brace
     } right curly brace
     ( left parenthesis
     ) right parenthesis
     : colon
     ; semicolon
     , comma
     - hyphen (dash)
     . period
     | vertical bar
     = equal sign
     " quote
     ' apostrophe
     a space (hex value '20'h)
     a tab (hex value '09'h)
     a page break (hex value '0c'h)

The additional ones are the remaining displayable characters in the 7-bit ASCII character set, and other displayable characters in other supported character sets.

From: dperkins@dsperkins.com
Status: rejected

A clear and concise definition is needed of the tokens of the MIB module language.

Suggested definition of tokens:

The characters in a MIB module file form a stream of tokens. The tokens are identifiers, keywords, literals (i.e., constants), punctuation, and white space. White space consists of space characters, line terminators, tab characters, page break characters, and comments. White space is ignored other than for use to separate otherwise adjacent identifiers, keywords, and literals. If the input has been parsed into tokens up to a given character, the next token is the longest string of characters that could possibly constitute a token.

From: dperkins@dsperkins.com
Status: accepted

A clear and concise definition is needed of comments in the MIB module language.

Suggested definition of comments:

A comment is started with a pair of adjacent hyphens (--) and is ended with the next pair of adjacent hyphens or the end of the line, whichever comes first. A conforming MIB compiler must support comments that include any of the printable characters in the 7-bit ASCII character set, spaces, tabs, and page breaks. A MIB compiler may support aditional characters from the ASCII character set, and may support characters from other character sets. A comment may occur between any two tokens and functions as white space.

(NOTE: Ending comments with dashes has caused problems in MIB module files. Some MIB compilers only support comment termination with end of line. The problems occur when 1) diagrams are specified in comments, 2) a line of dashes is used to separate sections of a MIB module file, and 3) "commenting out" sections of a MIB module file. When "commenting out" a section of a MIB module file, a pair of dashes in a commented out quoted string will terminate a comment, as well as the beginning of a comment in a commented out line. To solve these problems, I suggest that in a future version of the SMI a new comment type be created that starts with a different character sequence, such as //, and is only terminated with an end of line.)

From: dperkins@dsperkins.com
Status: rejected

A clear and concise definition is needed for identifiers in the MIB module language. Examples of identifiers include module names, "descriptors", labels for values of enumerated integers and bits, labels for component values in OID values, and the values of some clauses. For example, the values of the STATUS clause (which are "mandatory", "deprecated", and "obsolete") are identifiers. An example of a label for a component value in an OID value is "my-modules" in { myRoot my-modules(1) 43 }.

Suggested definition of Identifiers:

An identifier consists of 1 to 64 letters, digits, and hyphens. The initial character must be a letter. A hyphen cannot be the last character of an identifier. A hyphen cannot be immediately followed by another hyphen in an identifier. (NOTE: ASN.1 has no limit on number of characters in an identifier. Otherwise, the lexical rules for identifiers are identical.)

There are two types of identifiers which are distinguished by the case of the initial letter. A "ucName" is an identifier that starts with an uppercase letter. A "lcName" is an identifier that starts with a lowercase letter. Identifiers whose lengths are greater than 24 may cause compatibility difficulties with tools that process MIB modules.

Note that there are restrictions on use of hyphens in most identifiers. Those restrictions are noted in the grammar description.

(NOTE: the SMI does not allow hyphens in "descriptors" or in labels for values of enumerated integers and bits. It does allow hyphens elsewhere. Also, the SMI is silent on the max length of module names and labels for OID values. I think this was missed when the max size restriction was added.)

From: dperkins@dsperkins.com
Status: accepted

A clear and concise definition is needed for keywords in the MIB module language. This is needed to resolved the following issues:

a) Are ASN.1 keywords, which are not used in the MIB module language, reserved. (That is, can they be used for identifiers of textual conventions or module names? For example, "FALSE" is an ASN.1 keyword. Can a textual convention with descriptor FALSE be defined in a MIB module?)

b) Are the names of the SMI data types, such as Counter32, keywords? (If not, can they be used for the descriptor of a TC or a module name?)

c) Are the values of clauses in constructs keywords? For example, the OBJECT-TYPE construct contains a STATUS clause, with values "current", "deprecated", and "obsolete". Are these keywords? That is, can they be used for descriptors of items defined in a MIB module?

d) Are the identifiers used in clauses of constructs keywords? For example, in the OBJECT-TYPE construct, are the identifiers such as "SYNTAX", "MAX-ACCESS", "STATUS" keywords?

e) Are the names of constructs and the identifiers within them keywords "all the time" or "only after being imported"? For example, if a MIB module does not import NOTIFICATION-TYPE, is "OBJECTS" (a clause in the NOTIFICATION-TYPE construct), a keyword.

Sugguestion:

a) ASN.1 keywords not contained in the MIB module language are not reserved keywords of the MIB module language. However, the MIB module language should discourage use of all uppercase in the descriptors for textual conventions. Thus, the following are keywords in ASN.1, but are not keywords in the MIB module language:

          ABSENT, ANY, APPLICATION, BIT, BOOLEAN, BY, CHOICE,
          COMPONENT, COMPONENTS, DEFAULT, DEFINED, ENUMERATED,
          EXPLICIT, EXPORTS, EXTERNAL, FALSE, IMPLICIT, MAX, MIN,
          MINUS-INFINITY, NULL, OPTIONAL, PLUS-INFINITY, PRESENT,
          PRIVATE, REAL, SET, TAGS, TRUE, UNIVERSAL, and WITH

b) The keywords from ASN.1 used in the MIB module language, which are:

          BEGIN, DEFINITIONS, END, FROM, IDENTIFIER, IMPORTS,
          INCLUDES, INTEGER, OBJECT, OCTET, OF, SEQUENCE, SIZE,
          and STRING

and all the created data types, created construct names, and uppercase identifiers used in MIB module constructs, which are:

          ACCESS, AGENT-CAPABILITIES, AUGMENTS, BITS,
          CONTACT-INFO, CREATION-REQUIRES, Counter32, Counter64,
          DEFVAL, DESCRIPTION, DISPLAY-HINT, GROUP, Gauge32,
          IMPLIED, INDEX, Integer32, IpAddress, LAST-UPDATED,
          MANDATORY-GROUPS, MIN-ACCESS, MODULE,
          MODULE-COMPLIANCE, MODULE-IDENTITY, NOTIFICATION-GROUP,
          NOTIFICATION-TYPE, OBJECT-GROUP, OBJECT-IDENTITY,
          OBJECT-TYPE, OBJECTS, ORGANIZATION, Opaque,
          PRODUCT-RELEASE, REFERENCE, REVISION, STATUS, SUPPORTS,
          SYNTAX, TEXTUAL-CONVENTION, TimeTicks, UNITS,
          Unsigned32, VARIATION, and WRITE-SYNTAX

are always keywords.

c) The values in clauses of constructs, which are lowercase identifiers, are not keywords. Thus, they can be used for descriptors. The use in MIB modules should be discouraged.

d) Uppercase identifiers used in clauses of constructs are keywords (see b).

e) The imported data types, constructs (and identifiers within a construct) are always keywords regardless of whether they are imported or not. (see b)

MIB modules that demonstrate this issue:
SITESTROOT-MIB SITEST5-MIB SITEST6-MIB

From: dperkins@dsperkins.com
Status: rejected

A clear and concise definition is needed for punctuation tokens of the MIB module language.

Suggestion:

The following is a list of single characters used as punctuation tokens in the MIB module language:

     { left curly brace
     } right curly brace
     ( left parenthesis
     ) right parenthesis
     : colon
     ; semicolon
     , comma
     - hyphen (dash) (NOTE: this is used as a minus sign for numbers)
     . period
     | vertical bar

Note that the ASN.1 language includes characters "<", ">", "[", and "]" as punctuation tokens, which are not used in the MIB module language.

The following is a list of character combinations used as punctuation tokens in the MIB module language:

     .. two periods
     ::= two colons and an equal sign

From: dperkins@dsperkins.com
Status: rejected

A clear and concise definition is needed of number tokens of the MIB module language. ASN.1 does not define maximum values for numbers.

Suggested definition of numbers:

A number consists of one or more decimal digits. The first digit may not be zero unless the number is a single digit. A conforming MIB compiler must support numeric values up to 4294967295. A MIB compiler may support larger values. A numeric token does not include a sign. A sign is a separate token.

(NOTE 1: there is no limit on the maximum value of numbers in ASN.1.)

(NOTE 2: in a future version of the SMI, the max value needs to be increased to 2^64 - 1.)

From: dperkins@dsperkins.com
Status: accepted

A clear and concise definition is needed of hexadecimal and binary string tokens of the MIB module language. ASN.1 does not define maximum length of these tokens. (NOTE: the ASN.1 definition has changed between the 1987 and 1994 versions. Also, there are differences between the ASN.1 definitions and that allowed in MIB modules.)

Suggested definition of bin and hex strings:

A binary string consists of an arbitrary number (possibly zero) of zeros and ones, preceded by a single (') and followed by either the pair ('B) or ('b). A conforming MIB compiler must support lengths up to 128 binary digits. A MIB compiler may support longer lengths. When a binary string is used as a number, it is interpreted as an unsigned integer. It also must be between 1 and 32 (inclusive) bits long. When a binary string is used as the value for an OCTET STRING and the binary string is not a multiple of eight bits, it will be interpreted as if it contained additional zero trailing bits to make it the next multiple of eight.
(NOTE 1: ASN.1 terminates a binary string with only a ('B). Also, ASN.1 has no limit on the length of a binary string.)
(NOTE 2: ASN.1 does not allow binary strings to be interpreted as numbers.)

A hexadecimal string consists of an arbitrary number (possibly zero) of hexadecimal digits, preceded by a single (') and followed by either the pair ('H) or ('h). A conforming MIB compiler must support lengths up to 128 hexadecimal digits. A MIB compiler may support longer lengths. The hexadecimal digits are the characters "0", "1", "2", "3", "4", "5", "6", "7", "8", "9", "A", "a", "B", "b", "C", "c", "D", "d", "E", "e", "F", and "f". When a hexadecimal string is used as a number, it is interpreted as an unsigned integer. It also must be between 1 and 8 (inclusive) hexadecimal digits long. When a hexadecimal string is used as the value for an OCTET STRING and the hexadecimal string is not a multiple of 2 hexadecimal digits, it will be interpreted as if it contained an additional trailing zero hexadecimal digit.
(NOTE 1: ASN.1 terminates a hexadecimal string with only a ('H). Also, ASN.1 recognizes only the uppercase letters as hexadecimal digits and has no limit on the length of a hexadecimal string.)
(NOTE 2: ASN.1 does not allow hexadecimal strings to be interpreted as numbers.)

From: dperkins@dsperkins.com
Status: accepted

A clear and concise definition is needed of character string tokens of the MIB module language. Character string tokens are used as the value for many clauses, such as the DESCRIPTION clause found in many constructs and the value for OCTET STRING items in the DEFVAL clause of the OBJECT-TYPE construct. The SMI currently has no minimum maximum size.
(NOTE: the strings using in the MIB module language are not the character string tokens, called "cstrings" found in the ASN.1 language.)

Suggested definition character strings:

A character string token consists of an arbitrary number (possibly zero) of the 7-bit displayable ASCII characters except the quote character ("); and the nondisplayable tab, space, and line terminator characters. A character string token is preceded and followed by the quote character ("). A line terminator is encoded by a conforming MIB compiler in a character string token as a "nl" character (hex value '0a'h). A MIB compiler may use other encodings for a line terminator within a character string token. A conforming MIB compiler must support lengths up to 8192 characters (where line terminators are encoded as the single character 'nl') within a character string token. A MIB compiler may support longer lengths. (Note that the definition of character string tokens in the MIB module language is quite different from "cstrings" found in ASN.1.)

(NOTE: there is no way to include a quote (") in a character string token. Also, there is no way to include nondisplayable characters. In a future version, the rules for forming a character string token should be made to align with rules for common programming languages, such as C.)

From: dds@cnd.hp.com
Status: rejected

Issue #31 discusses the issue of the need for 64 bit integers beyond just counter64. It goes further and proposes a method for handling general unknown data types through the use of opaque encoding. I don't mind this being listed as a separate proposal to handle the issue of unknown data types. However, I would like to see a separate issue listed to the specific case of needing base 64 bit integer types. There is at least one case of a mib that could have used the 64 bit gauge -- the interfaces MIB contains a high speed gauge that was scaled, but would have been better as a 64 bit gauge in my opinion. Everyone generally agrees that this is an issue, and the disagreement is about whether and how to address it at this time.

Note: I very well understand that some people consider this "out-of-scope", and I understand that the design team may choose not to address it for this reason, though I disagree with this answer. Please list it as an issue with an "out-of-scope" resolution at least, so that this resolution can be legitimately discussed through the working group processes.

From: dperkins@dsperkins.com
Status: accepted

The sections in the SMI documents that specify conversion of GDMO (CMIP MIB specifications) should be removed from the SMI documents and put in a separate document. These sections do not define the MIB module language.

From: dperkins@dsperkins.com
Status: rejected

The SMI documents were not written using the RFC 2119 definitions of SHOULD/MUST/MAY. Thus, it is unclear to readers as to the requirements versus the strong recommendations.

I suggest that the SMI be rewritten using the terminology of RFC 2119. (Many hard decisions will have to be made as to the real intent.)

From: dperkins@dsperkins.com
Status: rejected

The MIB module language is defined by ASN.1, by text in the SMI RFCs (RFC 1902, RFC 1903, an RFC 1904), and by standard practices. It is quite difficult for users of the language or MIB compiler writers to determine what is valid and not valid in the language.

There needs to be a single document that specifies the grammar for the language in a format that can be easily read and understood, and used to create MIB compilers.

I suggest that such a grammar document be written using a simple BNF format (not the ABNF as specified in RFC 2234), which also includes the grammar in the format for YACC (with no error productions).

From: arnoud@nwn.com
Status: accepted

Something about the MODULE-IDENTITY construct that confused me was whether it is supposed to be a leaf construct (hanging under the companyModules subtree for ex.) or that managed objects can be hung under the MODULE-IDENTITY construct as well.

The Ethernet-like MIB (rfc1650) and the 802.5 MIB (rfc1748) use different approaches, so probably both are allowed, but since it confused me, maybe it needs some more clarification.

From: dperkins@dsperkins.com
Status: accepted

The SMI needs to clearly state the changes that are allowed in updates to MIB modules. These allowed changes should be specified in a document separate from the documents that define the MIB module language.

The "prime directive" of MIB module design must be clearly stated in the MIB module language specifications and the specification for allowed updates. It is needed in both because clean MIB design allows modifications without breaking the prime directive.

The Prime Directive is:

No change may be made in a published MIB module that will cause interoperation problems "over the wire" between implementations using an original specification and implementations using an updated specification (or specifications).

For IETF specifications, "published" means that the specification has been assigned an RFC number. Specifications made available on mailing lists or in the Internet-drafts repository are not published, and may be arbitarily changed.

From: dperkins@dsperkins.com
Status: rejected

The SMI does not indicate what is allowed to fix a flawed MIB module specification. For example, can OID values be changed if the OID values were mistakenly assigned. (This has happenned a few times in IETF MIB modules.)

Suggestion: Add text that allows publication errors to be corrected if noticed in a short amount of time before implementation has occured.

From: dperkins@dsperkins.com
Status: accepted

For all constructs that include a DESCRIPTION clause, the SMI MUST state that the content MAY be updated for clarification as long as the semantics are not changed.

From: dperkins@dsperkins.com
Status: rejected

The SMI MUST state that additions are allowed to comments as long as semantics are not changed. (Comments are used, unfortunately in many MIB files to specify semantics. In all cases the text of the comments SHOULD BE in DESCRIPTION clauses.)

From: dperkins@dsperkins.com
Status: accepted

The SMI does not specify allowed module-level changes. For example, can the name of a MODULE be changed? Can items be moved from one module to another?

Suggestion: Add text to strongly discourage and possibly disallow changing module names. Add text to allow moving items from one module to another (which may be newly created ones), and text to discourage such movement. Add text to note the problems with groups and compliances.

From: dperkins@dsperkins.com
Status: accepted

The SMI is not consistent in its coverage of the update of the status of items that contain a STATUS clause.

Suggestion: Specify in one place that the DESCRIPTION clause for an item must be updated for a change in value of a STATUS clause for an item. The DESCRIPTION clause MUST specifiy why the status was changed, and specify the replacements, if appropriate, for the item.

From: dperkins@dsperkins.com
Status: accepted

The SMI is unclear in its language as to whether the MODULE-IDENTITY specification MUST be or SHOULD be updated when a module is changed. Also, it is unclear what is to be modified in a MODULE-IDENTITY specification. The REVISION and the LAST-UPDATED clauses provide redundant information, and, thus, confuse MIB authors as to their intent. RFC 1902 is inconsistent in its specification of the REVISION clause. It says

      5.5.  Mapping of the REVISION clause
 
      The REVISION clause, which need not be present, is repeatedly
      used to describe the revisions (including the initial version)
      made to this information module, in reverse chronological order
      (i.e., most recent first).  Each instance of this clause contains
      the date and time of the revision.

which indicates that REVISION clauses are optional, but it they are used, then it specifies how they are used. If use of the REVISION clause is optional, then they have little or no value. (And possibly a cost.)

Suggestion: Clarify that a MODULE-IDENTITY specification MUST be updated by a REVISION/DESCRIPTION clause each time a module is updated, including the original publication. Also include examples showing the updating. (NOTE: for MIB modules in RFCs, the REVISION/DESCRIPTION clause is a very convenient place to specify the RFC number. For example,

    REVISION  "9806290000Z"
    DESCRIPTION "Published as RFC nnnn. Initial version.")

(NOTE: In future versions of the SMI, the LAST-MODIFIED-DATE clause needs to be removed, and the date format made to be in form YYYYmmdd (where YYYY is year, mm is month (1-12), and dd is day (1-31)).)

From: dperkins@dsperkins.com
Status: accepted

The SMI is not complete in its description of the allowed and not allowed updates to OBJECT-TYPE specifications.

1. It allows addition of values to enumerated integers. This is fine when the enumeration is a list of values, such as interface types, where there is an expectation that the list will grow over time. However, it also allows new values to be added when the enumeration is a list of "states", such as the states listed for object tcpConnState defined in RFC 1213. Such an addition, most likely, indicates a change of behavior of the resource being modeled, and, thus, a new object (or objects) need to be defined. Such an addition would break (or severely stress) interoperability between new and old implementations.

   Suggestion: clarify the text to state that enumerations MAY only be extended when the original DESCRIPTION indicates that they can be.

2. No statement is given as to whether the value of a SYNTAX clause can or cannot be updated with use, removal, or change of a textual convention. A change can be made as long as the semantics of the object type specification are unmodified. For example, there is no change of semantics when an object type specification uses a value for SYNTAX of OCTET STRING(SIZE(0..64)) and is updated to specify a value of DisplayString(SIZE(0..64)) as long as the text in the DESCRIPTION clause of the object type specification specifies the same as that for DisplayString.

   Suggestion: clarify the text to state that the value of the SYNTAX clause MAY be updated as long as the semantics of the object type specification are not changed. (Changing the base data type is a change in the semantics.)

3. No statement is given as to whether addition of named bits to a BITS pseudo data type is allowed, and, thus, disallows such modifications. However, as MIB authors have started to use BITS, many have found it useful to add BIT definitions for existing object type specifications. This is not allowed by the current SMI. When the object type specifications are a list of capabilities, then adding new BIT definitions is quite useful.

   Suggestion: add text to the SMI that allows addition of new bit values, if the text of the DESCRIPTION specifies that new values MAY be added.

4. The SMI states the rules for status changes, but it does not state the rules for second-order effects of status changes. That is, if the status of a table object is changed, then the corresponding row object and the contained columnar objects must be also updated. Also, the status for object groups must be updated, and event tables augmenting or extending the table must be updated.

   Suggestion: add text to the SMI that describes the status update second-order effect.

5. The SMI states in a round-about way that the semantics of an object type specification cannot be changed. The text from section 10.2 from RFC 1902 is:

           Otherwise, if the semantics of any previously defined object
           are changed (i.e., if a non-editorial change is made to any
           clause other those specifically allowed above), then the
           OBJECT IDENTIFIER value associated with that object must
           also be changed.
    
           Note that changing the descriptor associated with an existing
           object is considered a semantic change, as these strings may
           be used in an IMPORTS statement.
   

   Suggestion: Rewrite the above text to be clear. For example:

           An object type specification MUST NOT have its semantics
           changed. Semantics are changed when the base data type specified
           in the SYNTAX clause is changed or when the access specified in
           the MAX-ACCESS clause is changed. Also, semantics are changed
           when the indexing of a columar object is changed. A semantic
           change breaks interoperability between old and new
           implementations. In addition, the descriptor for an object
           type specification MUST NOT be changed because it can cause
           second order problems in IMPORTS clauses and compliance
           specifications that reference the descriptor. If new behavior
           is needed, an entirely new object type specification (or set
           of object type specificatons) must be created.
   

From: dperkins@dsperkins.com
Status: accepted

The SMI does not indicate that a SEQUENCE specification MAY BE updated, and MUST BE when a new columnar object type specification is added to a table.

Add text to indicate that a SEQUENCE specification MAY and MUST BE updated if and only if a new columnar object type specification is added to an existing table.

From: dperkins@dsperkins.com
Status: rejected

The SMI does not indicate the allowed changes for IMPORTS specifications.

Suggestion: Add text that allows IMPORTS to be updated to track the change of module name, change of descriptor, or movement of item to another module.

From: dperkins@dsperkins.com
Status: accepted

The SMI does not indicate the allowed changes for OID value assignment specifications.

Suggestion: Add rules that parallel those for OBJECT-IDENTITY specifications.

From: dperkins@dsperkins.com
Status: accepted

The SMI does not contain a section on updating TEXTUAL-CONVENTION specifications.

Suggestion: Add the rules for updating TCs. STATUS/DESCRIPTION/ REFERENCE updates just like OBJECT-TYPE update rules. SYNTAX update probably like SYNTAX update for OBJECT-TYPE. Rules for DISPLAY-HINT may be complicated.

From: dperkins@dsperkins.com
Status: accepted

The SMI does does not indicate the allowed changes for type assignment specifications. (That is, textual conventions without using the textual convention construct.)

Suggestion: Add rules that parallel those for textual convention specifications.

From: dperkins@dsperkins.com
Status: accepted

RFC 1904 has the same backwards way of saying that semantic changes are not allowed for conformance groups. Also, when the document was updated to add notification groups, an update of this section was overlooked.

Suggestion: Add detailed rules and examples for updates to both object and notification groups. Also add information about linkage of status of groups to the objects that are in the groups.

From: dperkins@dsperkins.com
Status: accepted

RFC 1904 has the same backwards way of saying that semantic changes are not allowed for module compliance specifications. Nothing is said about allowed updates to cope with renaming of modules and/or movement of groups from one module to another.

Suggestion: Add detailed rules and examples for updates to module compliances including allowed changes that are needed when modules are renamed and/or groups moved to different modules. Also add information that unlike groups, the status of a module compliance is not affected by a change in the status of a group.

From: dperkins@dsperkins.com
Status: accepted

RFC 1904 has the same backwards way of saying that semantic changes are not allowed for agent capabilities specifications. Nothing is said about allowed updates to cope with renaming of modules and/or movement of groups from one module to another.

Suggestion: Add detailed rules and examples for updates to agent capabilities including allowed changes that are needed when modules are renamed and/or groups moved to different modules. Also add information that unlike groups, the status of a agent capability is not affected by a change in the status of a group.

From: dperkins@dsperkins.com
Status: accepted

The specification for the BITS pseudo type is not complete in the SMI. BITS must look and work like all other types. The SMI documents allow BITS only to be specified in the OBJECT-TYPE and TEXTUAL-CONVENTION type constructs. BITS needs to be specified in the SEQUENCE, MODULE-COMPLIANCE, and AGENT-CAPABILITIES constructs. Also as currently specified, the SMI does not allow a default value for objects with resolved data type of BITS in the OBJECT-TYPE or AGENT-CAPABILITIES constructs. All of these problems with BITS need to be resolved.

Here is is an example of why the term "resolved data type" was used:

  MyTC ::= BITS{ red(0), green(1), blue(2) } -- note, this isn't even
                                             -- legal currently!
  myObj OBJECT-TYPE
    SYNTAX        MyTC
    MAX-ACCESS    read-only
    STATUS        mandatory
    DESCRIPTION   "object with default value and resolved
                  data type of BITS"
    DEFVAL        { {blue,red} }
    ::= { myEntry 45 }

The syntax of a BITS value needs to be defined for use in a DEFVAL clause. A proposal for the syntax is

   <bitsValue> = "{" <optBitList> "}"
 
   <optBitList> = empty | <bitList>
 
   <bitList> = <bitLabel> | <bitList> "," <bitLabel>
 
   <bitLabel> = lcName
 
   Where:
      lcName is a name that starts with a lowercase letter
      empty is an empty production
 
   The bit labels must be labels of bits in the resolved BITS data type.
   The lables can be in any order. A label can be specified at most once.

From: dperkins@dsperkins.com
Status: accepted

The IMPORTS construct is taken from ASN.1 without modification. However, the ASN.1 definitions are not well understood or implemented in MIB compilers. The ASN.1 syntax for the IMPORTS construct is the following productions (after translation to the form of BNF used in other examples):

  <Imports> = "IMPORTS" <SymbolsImported> ";" | empty
 
  <SymbolsImported> = <SymbolsFromModuleList> | empty
 
  <SymbolsFromModuleList> = <SymbolsFromModule> <SymbolsFromModuleList>
                          | <SymbolsFromModule>
 
  <SymbolsFromModule> = <SymbolList> "FROM" <ModuleIdentifier>
 
  <SymbolList> = <Symbol> "," <SymbolList> | <Symbol>
 
  <Symbol> = ucName | lcName
 
  <ModuleIdentifier> = ucName <AssignedIdentifier>
 
  <AssignedIdentifier> = <ObjectIdentifierValue> | empty

The ASN.1 specification has text to clarify the syntax.

The syntax for the IMPORTS clause needs to be included in the SMI documents. There are a few issues that also must be resolved:

1. I believe that ASN.1 specifies that a module can not be specified twice in the IMPORTS construct. For example, the following is not allowed:

        Integer32 FROM SNMPv2-SMI
        Counter32 FROM SNMPv2-SMI
   

   This needs to be verified and specified in the SMI.
2. An OID value may be specified after a module name to identify the module. As far as I can tell, only a single MIB compiler supports this, and, thus, I believe that it should be removed. An example is:

        MyTC FROM MY-MOD { 1 3 6 1 4 1 1194 3 0 7 }
   

3. And of course, the description of IMPORTS needs to say that an item cannot be specified more than once in an IMPORTS.
4. I cannot determine if ASN.1 allows items to be imported and not used. Text needs to say that this is legal, but discouraged.
5. The ASN.1 syntax for IMPORTS allows use of syntax:

         IMPORTS ;
   

   I couldn't find a reason why one would put this instead of not including an IMPORTS specification in an ASN.1 module. We need to determine what should be done about this.
6. In MIB modules, we need to say that it is OK to import appropriate items from modules written in one version of the SMI into other versions. And we need to say that data types and macros from one version cannot be imported into modules of another version. (NOTE: items that cannot be imported are SEQUENCES and v1 traps)

From: dperkins@dsperkins.com
Status: accepted

The meaning and use of the status clause is not well understood. This needs to be specified.

draft-rfced-info-perkins-status-02.txt explains the issue.

From: dperkins@dsperkins.com
Status: accepted

There is much confusion by user between OID value registration and OID value assignment. This need to be clarified. The following text describes the problem in detail:

The ASN.1 language has no direct mechanism to register an OID value to an item. Registration is accomplished in ASN.1 through processes outside of ASN.1 modules. Registration is the permanent assignment of an OID value to an item. After a valid registration, the OID value can not be registered to another item for all time; the assignment is remembered for all time; and the semantics of the item can not be changed for all time. Given the OID value, the item (after registration) can be positively identified, for all time. The MIB module language contains constructs which are used to perform registration. These constructs are OBJECT-TYPE, MODULE-IDENTITY, OBJECT-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP, NOTIFICATION-GROUP, MODULE-COMPLIANCE, and AGENT-CAPABILITIES. A item defined with one of these constructs is permanently assigned the OID value specified in that construct. That OID value can not be used for any other permanent assignment - a registration. However, the OID value assignment construct is not a permanent assignment. Below is an example of an OID value assignment:

        system OBJECT IDENTIFIER ::= { mib 1 }

This value assignment in a MIB module is not a registration. It is a convenience for the MIB designer to write the value { mib 1 }. Without such a shorthand mechanism, an OID value would need to be completely specified from the root or from an item with a permanently assigned OID value. For example, the OID value used in the OBJECT-TYPE construct for sysDescr would be specified as { iso 3 6 1 2 1 1 1 } instead of { system 1 }.

Note that it is valid in ASN.1 to write a module that contains more than one OID value assignment with the same OID value. This is shown below:

        v1 OBJECT IDENTIFIER ::= { mib 1 }
        v2 OBJECT IDENTIFIER ::= { mib 1 }

The SNMPv2 SMI is completely silent on this and related issues. For example, can a MIB module contain an OID value assignment and a registration with the same OID value? This shown below:

        s1 OBJECT IDENTIFIER ::= { system 1 }
        sysDescr OBJECT-TYPE
           -- clauses (omitted)
            ::= { system 1 }

The proper behavior is not well defined.

From: dperkins@dsperkins.com
Status: accepted

The nodes at the top of the OID value tree were assigned "well known" names by ISO and CCITT. ASN.1 compilers are expected to know these names. However, the list of names has expanded, and was changed when the CCITT changed its name to ITU. This is disruptive to MIB designers, users, and compiler writers. The MIB module language should use only the top level names:

   ccitt, iso, and joint-iso-ccitt

as specified in ASN.1-1987. These names MUST never be changed, or MAY new names added, since this is not installed base friendly.

From: dperkins@dsperkins.com
Status: accepted

When notification groups were added to the SMI, it appears that several places text should have been added, but wasn't.

The most important one is to specify that all notifications defined in a MIB module MUST be a member of at least one notification group of the MB module. If a notification is not included in a notification group, then 1) it is completely optional, which is a bad thing 2) it cannot be specified in a module compliance or agent capability

From: dperkins@dsperkins.com
Status: accepted

The rules of allowed indexing are stated in a roundabout way. The rules need to to clearly stated so that it can be determined what can be specified in an index clause. For example,
1) can scalars be specified
2) can the same column be specified more than once
3) can columns from other tables that are not index columns be specified
4) can index columns from another table be specified in a different order

For more details, see http://www.snmpinfo.com/tables.pdf.

From: dperkins@dsperkins.com
Status: rejected

There needs to be a separate document that describes translations between SMIv1 and SMIv2 in both directions. Currently, there is a single document that describes protocol issues and SMI issues. It doesn't describe translation in both directions.

From: dperkins@dsperkins.com
Status: accepted

There is confusion as to what objects can include a DEFVAL clause, and to what values can be specified.

Some people believe that a DEFVAL can be specified on any scalar, or columnar object (other than those with data type of Counter32/64). Others believe that a DEFVAL may be specified only for non-index columnar objects. Others believe that DEFVAL can be only be specified for non-index columns with access of read-create. This needs to be resolved.

The SMI does not indicate the approach to take when a single default value can not be used in all cases.

From: arnoud@nwn.com
Status: rejected

When describing an agent using AGENT-CAPABILITIES, it is now only possible to specify a subset of the MIB that the agent implements. I recently came upon a situation where my implementation (for some variables) supports a superset of a MIB.

When for instance security keys are the issue, it would be useful to indicate that the implementation actually supports a larger key length than specified in the MIB. This can't be done with AGENT-CAPABILITIES as far as I know. My question is: is this desired or is it just not something AGENT-CAPABILITIES is for, i.e., I must just add a private object with the larger key length?