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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 6 Jun 2000 23:05:24 +0200

Thanks for the reminder.

remops doc is in IETF Last Call

other docs are in my hands.

Bert

> ----------
> From: 	Randy Presuhn[SMTP:[email-masked]]
> Sent: 	Tuesday, June 06, 2000 10:19 PM
> To: 	Wijnen, Bert (Bert)
> Cc: 	[email-masked]; [email-masked]
> Subject: 	reminder: disman docs for "proposed"
> 
> 
> Hi -
> 
> I just checked http://www.ops.ietf.org/draft-status.html
> The status for these documents should be updated:
> 
>     draft-ietf-disman-notif-log-mib-16.txt
>     draft-ietf-disman-express-mib-11.txt
>     draft-ietf-disman-event-mib-09.txt
>     draft-ietf-disman-remops-mib-08.txt
> 
> All of these have completed WG last call.
> All have been approved by their respective reviewers.
> I have subsequently requested that these be taken to
> the IESG for consideration as proposed standards.
> 
> Is there any additional action needed from me or the WG?
> 
>  -------------------------------------------------------
>  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.
>  -------------------------------------------------------
>

---

From: Frank Strauss <[email-masked]>
Date: 07 Jun 2000 14:38:55 +0200

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: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 8 Jun 2000 13:46:07 +0200

OK... finally got to it.

Yep, WG Last Call completed, and IESG review basically also 
completed. The reviewers have given me their OK.
TTThe last check I do before IETF Last Call is a proper
compile (I use SMICng). If other compilers find real 
SMIv2 problems, then anybody can report those too.

Before I do the IETF Last Call, I would indeed want to see
the SMIv2 errors fixed. Other typo fixes can go along with
them, but they can also be done at a later time.
I would also prefer to fix SMI compile warnings if possible.

In general, pls also add the Disman WG chair contact info and
add info about the disman mailing list (where it is, how to
subscribe and where the archives are). This should be added to
the Description clause of each MODULE-IDENTITY.
W.r.t. contact info. I think it would be wise to list
Ramanathan as "editor", now it gives the impression that
he is the author. This would be good on title page and in
MODULE-IDENTITY description clause.

In the Event MIB, I wonder why we do not move section 7 to the 
Security Considerations section. Seems a bit strange to just
have two "Security" sections where the 2nd just points to the
first.

Same Security question for notificationLogMIb section 3.1.2.

I am adding the SMICng errors/warnings and I also have inline
comments on Randy's posting.

Bert
------------------ SMICng for eventmib -------
In file event.mi2
    32:                Published as RFC xxxxx"
    33:     ::= { mib-2 567 } - final assignment by IANA at publication time
E: Syntax error (ASN.1 comment line must start with two --

   887:     mteTriggerThresholdFallingEvent             SnmpAdminString
   888:     mteTriggerThresholdDeltaRisingEventOwner    SnmpAdminString,
E: Missing comma between sequence items

  1316:         control values in this entry."
  1317:     DEFVAL { '0'H }  -- No bits set.
E: hex string must be a multiple of 2 in length

   306:         same object may be somewhat redundant."
   307:     DEFVAL { boolean }
E: Default value for "mteTriggerTest" must be named bits in "{ }"

  1316:         control values in this entry."
  1317:     DEFVAL { '0'H }  -- No bits set.
E: Default value for "mteEventActions" must be named bits in "{ }"

------------- in expression MIB -----------

no errors

But I agree with Frank/Juergen that we better import zeroDotZero
from SNMPv2-SMI.

----------- in notificationLogMib -------

no errors

> Sent: 	Thursday, June 08, 2000 2:42 AM
> To: 	[email-masked]; [email-masked]
> Cc: 	[email-masked]
> Subject: 	Re: reminder: disman docs for "proposed"
> 
> 
> Hi -
> 
> Whoa.
> 
> We concluded WG last call on these long ago.
right

> 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.
agree

> 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.
agree

> 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 prefer to import zeroDotZero.
The hex value as currently defined in this MIB seems to be
complained about by at least 2 compilers, so I'd rather see
it fixed.

> 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.
> 
Consider this email as a request for one more cycle before I
issue IETF Last Call

> 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.
> 
Ram, now is the time for you to do some more work, pls
Thanks, Bert

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 8 Jun 2000 10:46:08 -0700 (PDT)

Hi -

> Date: Thu, 8 Jun 2000 09:22:13 +0200
> Message-Id: <[email-masked]>
> From: Juergen Schoenwaelder <[email-masked]>
> To: [email-masked]
> CC: [email-masked], [email-masked], [email-masked]
> In-reply-to: <[email-masked]> (message from Randy
> 	Presuhn on Wed, 7 Jun 2000 17:42:19 -0700 (PDT))
> References:  <[email-masked]>
> List-Id: IETF disman Working Group mailing list <[email-masked]>
...
> 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".) 
...

The missing "{}" in one defval is obviously a typo that should
be corrected during the publication process.  

I can't find anything to support the argument that the {
'0'H } is actually illegal (though the number of digits is
required to be even, so { '00'H } may be what was intended).
I don't like it, and would personally prefer the '{{}}'. 
However, I do not believe it is helpful to keep changing 
these drafts while they are in the hands of the IESG.

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

That fine with me.  My point is that this document is now
out of the WG's hands, and we should not be spinning another
draft unless requested by the IESG or AD.  Trivial corrections
like these are routinely handled during the publication process.
This stuff is even later than our other work items, and I will
not look favorably on further delay.

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 8 Jun 2000 12:09:07 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: [email-masked], Randy Presuhn <[email-masked]>
> Cc: [email-masked]
> Subject: RE: reminder: disman docs for "proposed"
> Date: Thu, 8 Jun 2000 13:46:07 +0200 
...
...

This is fine with me.  In addition to the fixes Frank has
identified (which are fine with me), here are the other typos
and potential IETF last-call issues that I've become aware of:

typo:
1) <draft-ietf-disman-event-mib-09.txt> Pages 6-7: it would
   be nice if the layout of the diagram
   were modified so that it would fit on a single page:

+--------------------------------+      subclassed by:
| mteTriggerEntry                |---+
|     { mteOwner,                |   +-- mteTriggerDeltaEntry
|       IMPLIED mteTriggerName } |   +-- mteTriggerExistenceEntry
|                                |   +-- mteTriggerBooleanEntry
|                                |   +-- mteTriggerThresholdEntry
|                                |
|             mteTrigger*Event ----------------------------->+
|             mteTriggerObjects --------------->+            |
|                                |              |            |
+--------------------------------+              |            |
                                                V            |
  +<--------------------------------------------+            |
  |                                                          |
  V                                                          |
+--------------------------------+                           |
| mteObjectsEntry                |                           |
|     { mteOwner,                |                           |
|       mteObjectsName,          |                           |
|       mteObjectsIndex }        |                           |
+--------------------------------+                           |
                                                             V
  +<---------------------------------------------------------+
  |
  V
+---------------------------------+
| mteEventEntry                   |
|     { mteOwner,                 |
|       IMPLIED mteEventName }    |
|                                 |
|               mteEventAction - - - - - - > +
|                                 |          |
+---------------------------------+          |
                                             | (condition)
   + - - - - - - - - - - - - - - - - - - - - + - - - - - - - -+
   |                                                          |
   |                                                          |
   V                                                          V
+------------------------------+   +------------------------------+
| mteEventSetEntry             |   | mteEventNotificationEntry    |
|     { mteOwner,              |   |     { mteOwner,              |
|       IMPLIED mteEventName } |   |       IMPLIED mteEventName } |
+------------------------------+   +------------------------------+

editorial:
2) <draft-ietf-disman-event-mib-09.txt> Page 9, last paragraph
   of "Security" should use subjunctive, since it is really a
   hypothetical example of just one possible policy. Minimal
   fix:  Change the following to the beginning of the paragraph
   from "All" to "If a security administrator were to employ
   such an approach, all".

editorial:
3) <draft-ietf-disman-event-mib-09.txt> Page 17, description of
   mteTriggerSampleType: the MUST is inappropriate.  This is
   advice, and is incorrect for things like the much-maligned
   zero-based counters.  Suggest "MUST -> "should".

typo:
4) <draft-ietf-disman-event-mib-09.txt> Page 33+. The description
   text for several definitions goes past column 72.  Add line
   breaks / reformat text as needed.

editorial:
5) <draft-ietf-disman-event-mib-09.txt> Page 35, definition of
   mteObjectsIndex, the word "small" is meaningless here,
   suggest deleting it.

editorial:
6) <draft-ietf-disman-event-mib-09.txt> Page 43, description of
   mteEventSetTargetTag: suggest replacing "MAY not accept"
   with "MAY reject" to avoid confusion.

typo:
7) <draft-ietf-disman-event-mib-09.txt> Page 58, copyright date.

typo:
8) <draft-ietf-disman-express-mib-11.txt> page 1, copyright date.

typo:
9) <draft-ietf-disman-express-mib-11.txt> page 4, "an managed" ->
   "a managed"

editorial:
10) <draft-ietf-disman-express-mib-11.txt> clause 3.5.2:
    Replace "The expression table, indexed by expression name,
    contains those" with "The expression table, indexed by
    expression owner and expression name, contains those".

    Replace "The object table, indexed by expression name and
    object index within" with "The object table, indexed by
    expression owner, expression name and object index within".

editorial:
11) <draft-ietf-disman-express-mib-11.txt> page 10: I can't find
    "weirdity" in my dictionaries.

editorial:
12) <draft-ietf-disman-express-mib-11.txt> page 11&12: "the user must"
    -> "the user would", since this is merely an example.

possible technical, I don't want to push it...
13) <draft-ietf-disman-express-mib-11.txt> page 19: the description
    of expExpression references DisplayString.  Why isn't this just
    UTF-8?

technical problem, solution agreed by WG at meeting long ago but not
reflected in I-D for all objects where this would be a problem:
14)  <draft-ietf-disman-express-mib-11.txt> page 25,
     expExpressionPrefix: The third paragraph calls for illegal
     BER (zero-length object identifiers are not permitted).
     I believe we already discussed this issue at one of the
     WG meetings, and the instruction to the editor at the
     time was to just use { 0 0 } for this case.  Note that
     the rest of the algorithm still works.  This also applies
     to expErrorInstance on page 28.

typo:
15)  <draft-ietf-disman-express-mib-11.txt> page 25: delete the
      superfluous comma in "Note that an object in the
      expression not being accessible,".

typo:
16)  <draft-ietf-disman-notif-log-mib-16.txt> page 1: copyright date

editorial:
17)  <draft-ietf-disman-notif-log-mib-16.txt> clause 3.1.1:
     change "MUST be modeled" to "is modeled here as".

technical issue, discussed at WG meetings but not reflected
in document:
18) draft-ietf-disman-notif-log-mib-16.txt> pages 4/5
    Heirarchically structured log names have been repeatedly
    shown to have subtle pitfalls.  The approach the draft
    recommends can produce surprises when the first subid of
    the second index looks like punctuation, etc.  For example,
    with { nlmLogName, nlmLogIndex, nlmLogVariableIndex
    }, nlmLogIndex could have the same value as "-", and
    nlmLogVariableIndex could match a particular subgroup
    name, thus (inappropriately) granting access

editorial:
19) draft-ietf-disman-notif-log-mib-16.txt> page 8: the
    various I-D revisions should all be collapsed into the
    "initial publication as RFC nnnn".

technical issue, discussed but not reflected in draft:
20)  draft-ietf-disman-notif-log-mib-16.txt> page 17: I
     thought we agreed that nlmLogEngineID's value would be
     a zero-length string, rather than not being instantiated.

editorial omission:
21)  draft-ietf-disman-notif-log-mib-16.txt> page 24: what
     is the condition for notificationLogDateGroup?

typo:
22)  draft-ietf-disman-notif-log-mib-16.txt> page 29: fix
     copyright date.

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 8 Jun 2000 12:19:55 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> Date: Thu, 08 Jun 2000 15:04:50 +0100
> From: rp <[email-masked]>
> To: [email-masked]
> References: <[email-masked]>
...
> draft-ietf-disman-expression-mib-11.txt file:
> 
> - on the expObjectIDWildcard description it is mentioned that
> "expExpressionPrefix will reflect a scalar object (ie will be 0.0)". On
> the other hand, on expExpressionPrefix description it says "If the
> expValueInstance portion of the value OID may be treated as a scalar
> (that is, normally, 0) the value of expExpressionPrefix is zero length,
> that is, no OID at all. Note that zero length implies a null OID, not
> the OID 0.0.". I think there is some incoherence here...

A zero-length OID isn't permitted by BER, so this text is broken
anyway.  This was discussed at one of the WG meetings, and not
reflected in the draft.  It needs to be fixed.

> - on the expObjectID description it is mentioned expObjectWildcard. I
> think it should be expObjectIDWildcard...
>
> - on the expObjectIDWildcard description it is mentioned
> expObjectWildcard. I think it should be expObjectIDWildcard...

You're right on both counts.  Ram: there are SEVERAL occurances
of expObjectWildcard throughout the document.  All should be
expObjectIDWildcard.

> - I presume that the expExpressionPrefix object value is implementation
> dependent, but I think it should be mentioned in the document if it can
> be equal to any of the wildcarded expObjectID of the expression and, if
> so, which one of them (any/first/last/shorter...).

I think that's what the last paragraph of the object's description is
trying to say: it will indeed be the expObjectID value of one of the
wildcarded objects.  Just which one is entirely up to the implementation.

> Well, I am sorry if this remarcs are some how irrelevant, but I believe
> they can help to improve the document.
...

Thanks for the comments.  It would have been nice if they had
arrived during WG last call or earlier.