Technical University Braunschweig - Computer Science - Operating Systems and Computer Networks

From: mikek@iwl.com
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.

From: remoore@us.ibm.com
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.

From: remoore@us.ibm.com
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.

From: remoore@us.ibm.com
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.

From: RPATZER1@email.mot.com
Status: accepted

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

draft-ops-smiv2-conf-00.txt

• Page 11, Section 3, 3rd paragraph, make "provide" plural "provides" - ..."macro itself provides no..."
• Page 11, Section 3.1, 1st para., Did you mean to include also "write-only"?
• Page 11, Section 3.2, recommend first sentence be cut and replaced by Section 6.2 sentene for consistency.
• Page 14, Section 4.2, 1st sentence, same as above
• Page 16, Section 5.1, " " " " " "
• Page 22, Section 6.5.1, should it read "The INCLUDES clause, which need not be present but, which must be present ..."?

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.

From: apb@iafrica.com
Status: rejected

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

" SNMPv2-SMI DEFINITIONS ::= BEGIN
"
" -- 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.

From: heard@vvnet.com
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.

From: johnf@hprnljf.rose.hp.com
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:

• notReady means that columns are missing. A row where all columns exist cannot be notReady
• a row cannot transition from notInService to notReady
• notInService has no implication regarding the internal consistency of the row, availability of resources, or consistency with the current state of the system
• the note:

              NOTE: Other processing of the set request may result in a
              response other than noError being returned, e.g.,
              wrongValue, noCreation, etc.
  

  applies to the entire state table, and means that notInService->active is allowed to fail.

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.