Subject: Re: reminder: disman docs for "proposed"

From: Randy Presuhn <[email-masked]>
Date: Wed, 7 Jun 2000 17:42:19 -0700 (PDT)

Hi -

Whoa.

We concluded WG last call on these long ago.

I have no problem with fixing typos as part of the IETF last
call, when it is issued, or even during the RFC-editing cycle,
since the missing commas and curleys are simple typos, and
these are routinely handled in that phase.

Changing the "xxxxx" for the RFC number, the revision and
last-updated clauses seems pointless, since all those are
modified during the publication process anyway.

The local definition of zeroDotZero, and using a hex value
for a BITS are at best stylystic quibbles, rather than
clear-cut errors.  I don't object to the change, but also
see no reason to change them, unless a convincing argument
for such changes is raised in IETF last call or by the IESG.

I do NOT want to see another draft cycle while the documents
are in the hands of the IESG unless the IESG or our AD
requests it.  With three related documents in a batch, things
are confusing enough as it is.

Ram, you should be tracking any potential deltas due to the
discovery of typos very carefully at this point, since there
may be other deltas introduced by the RFC editor.

 -------------------------------------------------------
 Randy Presuhn           [email-masked]
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141
 Fax:   +1 408 965-0359  2141 North First Street
 http://www.bmc.com/     San José, California 95131  USA
 -------------------------------------------------------
 My opinions and BMC's are independent variables.
 -------------------------------------------------------

> Message-Id: <[email-masked]>
> Date: Wed, 07 Jun 2000 14:21:31 -0700
> To: Frank Strauss <[email-masked]>
> From: Ramanathan Kavasseri <[email-masked]>
> Subject: Re: reminder: disman docs for "proposed"
> Cc: [email-masked]
> In-Reply-To: <[email-masked]>
> References: <[email-masked]'s message of "6 Jun 2000 22:30:14 +0200">
>  <[email-masked]>
> 
> Frank,
> 
> I've made the changes you requested for the event and expression mibs -
> would you like me to send them to you first for verification, or rightaway
> submit them as
> draft-ietf-disman-event-mib-10.txt and draft-ietd-disman-express-mib-12.txt?
> 
> Thanks for pointing the errors to me.
> 
> Ram
> 
> At 02:38 PM 6/7/00 +0200, you wrote:
> >
> >Randy> I just checked http://www.ops.ietf.org/draft-status.html
> >Randy> The status for these documents should be updated:
> >
> >Randy>     draft-ietf-disman-notif-log-mib-16.txt
> >Randy>     draft-ietf-disman-express-mib-11.txt
> >Randy>     draft-ietf-disman-event-mib-09.txt
> >Randy>     draft-ietf-disman-remops-mib-08.txt
> >
> >Randy> All of these have completed WG last call.
> >Randy> All have been approved by their respective reviewers.
> >Randy> I have subsequently requested that these be taken to
> >Randy> the IESG for consideration as proposed standards.
> >
> >I've checked the SMI modules of these documents with libsmi's smilint
> >and took a very rough look. I suggest the following changes to the
> >event and expression MIBs.
> >
> >
> >--- orig/DISMAN-EVENT-MIB       Wed Jun  7 14:07:48 2000
> >+++ fixed/DISMAN-EVENT-MIB      Wed Jun  7 14:23:01 2000
> >@@ -14,7 +14,7 @@
> >     SnmpAdminString           FROM SNMP-FRAMEWORK-MIB;
> > 
> > dismanEventMIB MODULE-IDENTITY
> >-    LAST-UPDATED "200001060000Z"            -- 6 January 2000
> >+    LAST-UPDATED "200006070000Z" -- 7 June 2000
> >     ORGANIZATION "IETF Distributed Management Working Group"
> >     CONTACT-INFO "Ramanathan Kavasseri
> >                   Cisco Systems, Inc.
> >@@ -27,10 +27,10 @@
> >      for network management purposes."
> > -- Revision History
> > 
> >-       REVISION     "200001060000Z"            -- 6 January 2000
> >+       REVISION     "200006070000Z"            -- 7 June 2000
> >        DESCRIPTION  "This is the initial version of this MIB.
> >-               Published as RFC xxxxx"
> >-    ::= { mib-2 xx } - final assignment by IANA at publication time
> >+               Published as RFC xxxx"
> >+    ::= { mib-2 xx } -- final assignment by IANA at publication time
> > 
> > dismanEventMIBObjects OBJECT IDENTIFIER ::= { dismanEventMIB 1 }
> > 
> >@@ -331,7 +331,7 @@
> > 
> >         Note that combining 'boolean' and 'threshold' tests on the
> >         same object may be somewhat redundant."
> >-    DEFVAL { boolean }
> >+    DEFVAL { { boolean } }
> >     ::= { mteTriggerEntry 4 }
> > 
> > mteTriggerSampleType OBJECT-TYPE
> >@@ -973,7 +973,7 @@
> >     mteTriggerThresholdRisingEventOwner         SnmpAdminString,
> >     mteTriggerThresholdRisingEvent              SnmpAdminString,
> >     mteTriggerThresholdFallingEventOwner        SnmpAdminString,
> >-    mteTriggerThresholdFallingEvent             SnmpAdminString
> >+    mteTriggerThresholdFallingEvent             SnmpAdminString,
> >     mteTriggerThresholdDeltaRisingEventOwner    SnmpAdminString,
> >     mteTriggerThresholdDeltaRisingEvent         SnmpAdminString,
> >     mteTriggerThresholdDeltaFallingEventOwner   SnmpAdminString,
> >@@ -1448,7 +1448,7 @@
> > 
> >         For 'set', an SNMP Set operation is performed according to
> >         control values in this entry."
> >-    DEFVAL { '0'H }  -- No bits set.
> >+    DEFVAL { {} }  -- No bits set.
> >     ::= { mteEventEntry 3 }
> > 
> > mteEventEnabled OBJECT-TYPE
> >@@ -2014,7 +2014,7 @@
> >                 mteTriggerThresholdRisingEventOwner,
> >                 mteTriggerThresholdRisingEvent,
> >                 mteTriggerThresholdFallingEventOwner,
> >-                mteTriggerThresholdFallingEvent
> >+                mteTriggerThresholdFallingEvent,
> >                 mteTriggerThresholdDeltaRisingEventOwner,
> >                 mteTriggerThresholdDeltaRisingEvent,
> >                 mteTriggerThresholdDeltaFallingEventOwner,
> >--- orig/DISMAN-EXPRESSION-MIB  Wed Jun  7 14:09:56 2000
> >+++ fixed/DISMAN-EXPRESSION-MIB Wed Jun  7 14:23:06 2000
> >@@ -4,14 +4,14 @@
> >     MODULE-IDENTITY, OBJECT-TYPE,
> >     Integer32, Gauge32, Unsigned32,
> >     Counter32, Counter64, IpAddress,
> >-    TimeTicks, mib-2               FROM SNMPv2-SMI
> >+    TimeTicks, mib-2, zeroDotZero       FROM SNMPv2-SMI
> >     RowStatus, TruthValue, TimeStamp    FROM SNMPv2-TC
> >     sysUpTime                 FROM SNMPv2-MIB
> >     SnmpAdminString           FROM SNMP-FRAMEWORK-MIB
> >     MODULE-COMPLIANCE, OBJECT-GROUP     FROM SNMPv2-CONF;
> > 
> > dismanExpressionMIB MODULE-IDENTITY
> >-    LAST-UPDATED "9910220000Z"
> >+    LAST-UPDATED "200006070000Z" -- 7 June 2000
> >     ORGANIZATION "IETF Distributed Management Working Group"
> >     CONTACT-INFO "Ramanathan Kavasseri
> >                   Cisco Systems, Inc.
> >@@ -24,9 +24,9 @@
> >      management purposes."
> > -- Revision History
> > 
> >-       REVISION     "9910220000Z"            -- 22 October 1999
> >+       REVISION     "200006070000Z"            -- 7 June 2000
> >        DESCRIPTION  "This is the initial version of this MIB.
> >-               Published as RFC xxxxx"
> >+               Published as RFC xxxx"
> >     ::= { mib-2 xx } -- final assignment by IANA at publication time
> > 
> > 
> >@@ -952,8 +952,6 @@
> >      'deltaValue' or 'changedValue'."
> >     DEFVAL      { timeTicks }
> >      ::= { expObjectEntry 7 }
> >-
> >-zeroDotZero OBJECT IDENTIFIER ::= { 0 0 }
> > 
> > expObjectConditional OBJECT-TYPE
> >     SYNTAX      OBJECT IDENTIFIER
> >
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Jun 2000 09:22:13 +0200

>>>>> Randy Presuhn writes:

Randy> I have no problem with fixing typos as part of the IETF last
Randy> call, when it is issued, or even during the RFC-editing cycle,
Randy> since the missing commas and curleys are simple typos, and
Randy> these are routinely handled in that phase.

Some of the problems discovered by Frank are clear SMIv2 violations
and thus I would indeed call them errors. (For example, the DEFVALs
for BITS are just illegal - this is not a "stylystic quibble".) 

Sure, these SMIv2 problems should be catched during the MIB quality
review anyway. Just consider Frank's message as input for this
review...

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>