Technical University Braunschweig - Computer Science - Operating Systems and Computer Networks
Comments received during SMIv2 Last Call
#1INTEGER vs Integer32 in enumerations
Status: accepted

Section 7.1.1, w.r.t Integer32, INTEGER and enumerations, is somewhat ambiguous in whether or not both INTEGER and Integer32 are allowed to have named values. Integer32 is "indistinguishable from INTEGER" -- so does this mean that Integer32 can have named values too? I don't recall seeing Integer32 ever used in this manner. This might be something to clarify.

Resolution: Clarified that Integer32 is not allowed to have named values.

#2management protocol restrictions in SMIv2
Status: accepted

The following paragraph appears on p. 36:

Further note that although conceptual tables and rows are given administratively assigned names, these conceptual objects may not be manipulated in aggregate form by the management protocol.
There's no reason for this paragraph to be here. It's a property of SNMP, not of SMI, that it does not deal with conceptual table rows. At the last IETF, Keith proposed that SMI be the language for modeling policy information for the COPS protocol to transport, in which case it *would* be conceptual rows that the protocol would "manipulate". Bob Stewart and others have also proposed designs where SNMP's rule of "a full instance ID for each object" is relaxed, to improve efficiency on the wire.

SMI is a language for modeling management information, with only a historical tie to the SNMP protocol. By removing this paragraph, we wouldn't introduce any confusion about how SNMP transports SMI-defined information, since the SNMP standards are quite clear on this. What we would remove is the misguided suggestion that SMI SHALL / SHOULD be used *only* by management protocols that limit themselves to dealing with single objects.

Resolution: The paragraph has been removed.

#3TDomain/TAddress references
Status: accepted

The definitions of TDomain (p.22) and TAddress (p.23) refer to the SNMPv2-TM module, without indicating where to find this module. These two TCs should have REFERENCE clauses that point to RFC 1906, and RFC 1906 should be added to the list of references in section 8.

Resolution: References have been added.

#4TC subtyping
Status: rejected

First, I apologize if this point has been discussed and resolved while I've been off in LDAP schema land the past few months, but ....

Section 3.5 (p. 27) doesn't look at all like I expected it to. I thought there was general consensus to let a TC refine the syntax of another TC. Did we really reach a consensus *not* to allow this, as the first paragraph of section 3.5 states?

Resolution: The consensus was to not allow a TC to be defined in terms of another TC.

#5editorial comments
Status: accepted

I have reviewed your SMIv2 drafts and have some recommended revisions and questions:


draft-ops-smiv2-smi-00.txt and the Textual Conventions for SMIv2 drafts look good to go.

Resolution: Editorial comments generally accepted, but "write-only" is illegal.

#6definition of iso
Status: rejected

In draft-ops-smiv2-smi-00.txt you say:

" -- the path to the root
" org            OBJECT IDENTIFIER ::= { iso 3 }
" dod            OBJECT IDENTIFIER ::= { org 6 }
" internet       OBJECT IDENTIFIER ::= { dod 1 }
Please add a definition for "iso", so that we have a complete path all the way from the root (or "to the root", if you want to look at it that way).

Resolution: "iso" can not be defined using a valid ASN.1 OID definition.

#7typos in updated SMIv2 drafts
Status: accepted

I think the word "underlying" was mis-spelled as "underingly" in draft-ops-smiv2-smi-00.txt and draft-ops-smiv2-tc-00.txt at the placed indicated below.

% grep -n underingly  draft-ops-smiv2-*-00.txt
draft-ops-smiv2-smi-00.txt:1384:is allowed, as appropriate to the underingly ASN.1 type.  Any such
draft-ops-smiv2-tc-00.txt:1546:is allowed, as appropriate to the underingly ASN.1 type.  Any such

Resolution: Typo has been fixed.

#8RowStatus state transitions
Status: accepted

Discussion on the snmpv3 mailing list last week indicated that there is a section of the "Textual Conventions for SMIv2" document that has been frequently misinterpreted, and should probably be clarified.

The state transition table for the RowStatus textual convention has been misinterpreted by many implementors to mean that transitions from notInService to active MUST succeed. This interpretation would require that a row cannot be in the notInService state unless it is internally consistent, consistent with the current state of the system, and resources are known to be available to make it active. It also leads to a misinterpretation of the notReady state, which was intended to mean that there are columns missing that need to be created before the row is made active.

This issue was discussed on the snmpv2 mailing list back in May 1996, with the conclusion that:

However, this interpretation is still not clear in the draft (the relevant text is unchanged from RFC 1903). Discussion on the snmpv3 mailing list in the last week indicates that some implementors are still misinterpreting this.

I feel that it would be wise to add clarifying text to the description of the RowStatus TC regarding the above points, and that the cell in the state transition table for the transition from notInService->active should refer to a note containing clarification that the transition may fail.

Resolution: The missing clarifications have been included.

© IBR, TU Braunschweig, last updated 25-01-1999 15:59:34 by Juergen Schoenwaelder <>