Subject: [Disman] AD review of: draft-ietf-disman-conditionmib-08.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 6 Jun 2003 15:31:57 +0200

Here is my review of rev 8.

If you want, we can issue IETF Last Call, and then you may
consider these comments as IETF Last Call Comments, that you
better address rigth after such an IETF Last Call.

More or less serious:

- I see
    IANAItuProbableCauseOrZero ::= TEXTUAL-CONVENTION
      STATUS  current
      DESCRIPTION
       "This TC can take any value of IANAItuProbableCause or 0.
        IANAItuProbableCause is defined in the IANA-ITU-ALARM-TC
        module in the Alarm MIB document (see RFC zzzz)."
      REFERENCE
        "RFC zzzz - Alarm MIB, Chisholm, S. and D. Romascanu, mmm 2002."
    -- RFC Ed.: replace zzzz with the RFC number of the Alarm MIB document, 
    --          replace mmm with the actual month, and remove this notice.
  And so I wonder. That IANA mantained MIB module will be extracted from
  the document, and after that, the authoritative version will be at
  the iana web site as follows: 
       http://www.iana.org/assignments/ianaitualarmtc-mib   
  Now putting a url into the REF clause is not good either, but maybe
  something aka:
      REFERENCE
        "IANA-ITU-ALARM-TC MIB module as maintained at the IANA web site.
         The initial module was also published in RFC zzzz."
  However, you do want to add that 
        http://www.iana.org/assignments/ianaitualarmtc-mib 
  in the normative references section, cause one must understand it in 
  order to udnerstand your TC and how it is used.

- I believe that the arcEntry should include in its DESCRIPTION clause
  some text about the fact that the indexing can cause OIDs of more
  than 128 sub-IDs (which are not supported bu SNMPv1, SNMPv2c or SNMPv3).
  This is caused by OIDs for ResourceId syntax of arcIndex and for 
  arcNotificationId. So some text as to how people can/should avoid 
  an OID of more than 128 sub-IDs shoiuld be added.

- arcRowStatus OBJECT-TYPE
  In the DESCRIPTION clause, pls describe if any objedcts in a row can
  or cannot be updated while the row is in active state. Such is required
  as per RFC2579.

Questions:
- I see
      arcTITimeInterval OBJECT-TYPE
         SYNTAX  Gauge32
  and
      arcCDTimeInterval OBJECT-TYPE
         SYNTAX  Gauge32
  is that a proper syntax for an interval ??
  there are a few more of these.

- I see two informative references (RFC1213 and RFC2863), but I do not
  see any citations to it. So are they needed or useful?

NITS:

- Can you do real pagination?

- I see " This document defines the SNMP objects..."
  I think they are "MIB  objects" rather than "SNMP objects"

- I see "  The ARC MIB defined in" a few times. 
  I think it is better to write "The ARC MIB module ....."

- I see:
      DESCRIPTION
         "The MIB module describes the objects for controlling a resource
          in reporting alarm conditions that it detects.

            Copyright (C) The Internet Society (2003).  This version
            of this MIB module is part of RFC yyyy;  see the RFC
            itself for full legal notices."
  -- RFC Ed.: replace yyyy with actual RFC number & remove this note
      REVISION  "200304160000Z"
      DESCRIPTION
         "Initial version, published as RFC xxxx."
  -- RFC Ed.: replace xxxx with actual RFC number & remove this note
      ::={ mib-2 yy }   --  to be assigned by IANA
  -- RFC Ed.: replace yy with IANA-assigned number & remove this note
  It might be easier if you used xxxx instead of yyyy, After all,
  these are both going to be the same RFC number, no?

bert