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

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 16 Jul 2003 13:46:20 -0400

Bert and all,

Inline below are the proposed changes to the document in response to Bert's reveiw comments. If no objection to the changes, I will produce version -09 and upload it next week after the repository open again.

Regards,
Kam

> -----Original Message-----
> From: Wijnen, Bert (Bert) 
> Sent: Friday, June 06, 2003 9:32 AM
> To: Lam, Hing-Kam (Kam); [email-masked]'; 'David Perkins'
> Cc: Disman (E-mail) (E-mail)
> Subject: AD review of: draft-ietf-disman-conditionmib-08.txt
> 
> 
> 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.

Replace 
    REFERENCE
      "RFC zzzz - Alarm MIB, Chisholm, S. and D. Romascanu, mmm 2002."
with 
    REFERENCE
      "IANA-ITU-ALARM-TC MIB module as maintained at the IANA web site.
       The initial module was also published in RFC zzzz."

Add
    [ITUALARMTC]   http://www.iana.org/assignments/ianaitualarmtc-mib 
to the normative reference. 

Also add citation to the URL by replacing the last sentence of the 
6th paragraph of section 4 by
   These probable causes (alarm conditions) have
   been included in the IANAItuProbableCause TC, which is defined in
   the IANA-ITU-ALARM-TC MIB module [RFCzzzz]. The IANA-ITU-ALARM-TC 
   MIB module is maintained in the IANA web-site [ITUALARMTC].

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

Add the following text to the DESCRIPTION clause of arcEntry

   Implementation need to be aware that if the total size of
   arcIndex and arcNotificationId exceeds 114 sub-IDs, then OIDs 
   of column instances in this table will have more than 128 
   sub-IDs and cannot be access using SNMPv1, SNMPv2c, or snmpv3.

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

Add the following text in the DESCRIPTION clause of arcRowStatus OBJECT-TYPE

    Only the objects arcState and arcNalmTimeRemaining can be updated
    when a row is active.

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

Change the syntax of arcTITimeInterval, arcCDTimeInterval, and
arcNalmTimeRemaining from Gauge32 to Unsigned32.

In the IMPORTS clause, replace Gauge32 by Unsigned32.

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

Remove RFC1213 and RFC2863 from the informative references.

> 
> NITS:
> 
> - Can you do real pagination?

Will do.

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

Will change.

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

Will change.

> 
> - 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?

Will change.

> bert

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 16 Jul 2003 13:46:20 -0400

Bert and all,

Regards,
Kam

Replace 
    REFERENCE

Add

Will do.

Will change.

Will change.

Will change.

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 16 Jul 2003 20:40:47 +0200

Sound good, but w.r.t. 
> Add the following text in the DESCRIPTION clause of 
Liteally it is incorect, cause I think that arcRowStatus itself can
also be updated/changed, no?

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 16 Jul 2003 20:40:47 +0200

Sound good, but w.r.t. 

Bert

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 17 Jul 2003 14:54:51 -0400

> also be updated/changed, no?

Yes, it is an oversight. The sentence will be:

    Only the objects arcState, arcNalmTimeRemaining, and arcRowStatus 
    can be updated when a row is active.

Regards,
Kam

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 17 Jul 2003 14:54:51 -0400

Regards,
Kam