Subject: [Disman] AD review of: draft-ietf-disman-alarm-mib-09.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 15 Mar 2003 21:38:19 +0100

Sorry that it took so long.

- New MIB boilerplate is now prefered
  see www.ops.ietf.org 
  Nice thing is that it is much shorter and has far less
  references.
- New MIB security guidelines to be followed
  see www.ops.ietf.org 
  This one is a bit more elaborate than what you currently have
- We want MIB COPYright in the MODULE-IDENTITY in the DESCRIPTION
  clause. See recent discussions on MIBS mailing list and in
     draft-ietf-ops-mib-review-guidelines-01.txt

- Page 4, you may want to add [RFC2119] refernece to the text

- In the IANA maintained IANA-ITU-ALARM-TC mib, pls add in 
  DESCRIPTION clause the rules/guidelines for IANA on how to 
  add/change stuff in this MIB module.
  Pls also add (or instruct RFC-editor to add) a (normative reference)
  to the iana web site where this IANA maintained MIB module will be 
  placed. Also, add text to make it clear that this is only the 
  initial module and that the authoritative copy to be referenced
  in any future document must be the one at iana web site.
  Not sure if this was posted anywhere yet (it should show up in our
  IESG minutes), but 20 Feb, IESG discussed this in their bi-weekly
  telechat. Here is the result:

     The IESG discussed if new IANA-maintained MIB modules
     should be published as (part of) an RFC. The consensus 
     is that the initial version indeed is to be in an RFC.
     The version in that RFC MUST make sure that some 
     statement is made that the authoritative version of
     the IANA-maintained MIB module is at the IANA web pages.

  I guess 2nd para in sect 5.2 does that. May want to add the ref to
  the iana web page to be

- ianaItuAlarmNumbers MODULE-IDENTITY
  needs a REVISION clause

- I prefer to see
     ::= { mib-2 xx}  -- to be assigned by IANA
  That is, add the comment that IANA needs to assign a value
  So that IANA can clearly see where they need to do things
  This holds for all MIB modules.
  In fact, I would change this:
         DESCRIPTION
             "Initial version, published as RFC XXXX."

         ::= { mib-2 xx }
  Into
         DESCRIPTION
             "Initial version, published as RFC XXXX."
             -- RFC-Editor assigns XXXX
         ::= { mib-2 xx } -- to be assigned by IANA

- When I see:     ResourceId ::= TEXTUAL-CONVENTION
  then I wonder... is this indeed a "resourceId" in the generic sense,
  or have we limited it here for the ALARM-MIB type of resources?
  In other words, would it maybe better to name it:
       AlarmResourceId ::= TEXTUAL-CONVENTION
  This to avoid conflict with other types of Resources?

- I see:
   alarmModelVarbindIndex  OBJECT-TYPE
      SYNTAX  Integer32
  Does a negative value ever make sense?
  Is an Unsigned32 SYNTAX better?

- I cannot find a StorageType object or any text in a DESCRIPTION clause
  that explains the persistency behavioru for alarmModelTable
  I believe this is so for more tables in this(these) MIB module(s)

- I see:
   alarmActiveEngineID OBJECT-TYPE
      SYNTAX      SnmpEngineID
      MAX-ACCESS  read-only
      STATUS      current
      DESCRIPTION
          "The identification of the SNMP engine at which the alarm
          originated.
          If the alarm list can contain alarms from only one
          engine or the alarm is from an SNMPv1 system, this object is
          a zero length string."
  But... the SnmpEngineID as specified in RFC3411 has a SIZE(5..32).
  So it cannot be a zero length string. What you need is a 
  LocalSnmpEngineOrSnmpEngineID or some such. The PM-MIB in SNMPCONF
  WG had same problem. In rev 13, they now have:
    pmRoleContextEngineID OBJECT-TYPE
      SYNTAX      OCTET STRING (SIZE (0 | 5..32))
  Maybe this calls for a common TC ?? If not, then you can solve it
  in a similar way

- I see: 
   alarmActiveContextName OBJECT-TYPE
      SYNTAX      SnmpAdminString
  I wonder if it would not be (much) better to do:
   alarmActiveContextName OBJECT-TYPE
      SYNTAX      SnmpAdminString (SIZE (0..32))
  After all, a contextName can only have that size as far as I know.
  Or at least, we use that size in all the SNMP MIB mdoules we have
  created sofar.
  Occurs in alarmClearTable also

- I see:
   alarmClearMaximum OBJECT-TYPE
    SYNTAX Integer32
  Would a negative value ever make sense?

- I see Underscores in the IANA-ITU-ALARM-TC mib. Formally they are not allowed.
  So why are we doing this? I do not see a good reason. Can we not just
  leave the underscore out?
  Maybe this was discussed on WG ..
  pls refresh my memory if so.

- SMIlint tells me about ITU-ALARM-MIB:
    .\ITU-ALARM-MIB:359: warning: current group `ituAlarmServiceUserGroup'
    is not referenced in this module
    .\ITU-ALARM-MIB:369: warning: current group `ituAlarmSecurityGroup'
    is not referenced in this module
    .\ITU-ALARM-MIB:380: warning: current group `ituAlarmStatisticsGroup'
    is not referenced in this module
  Now... it is not mandatory to reference it. But see bottom of
  page 23 of draft-ietf-ops-mib-review-guidelines-01.txt which
  recommends to actually list them
- SMIlint tells me about ALARM-MIB:
    .\ALARM-MIB:967: warning: current group `alarmActiveStatsGroup'
    is not referenced in this module
    .\ALARM-MIB:980: warning: current group `alarmClearGroup' is
    not referenced in this module
    .\ALARM-MIB:997: warning: current group `alarmNotificationsGroup'
    is not referenced in this module
  Same comments as above.
- I am missing an IPR statement.
- when you do an update, pls update the year for the copyrigth statements
  in various places.
- same for dates in MIB modules.
- Pls realize that RFCs that contain MIB modules from which you IMPORT
  anything must be referenced in a normative way. I say this, cause
  for example the new boilerplate no longer refrences RFC3411, but since
  you IMPORT from the MIB module in that doc, it should still be listed
  as noramative reference.
- I believe that the WG mailing list has moved to IETF site, so pls
  update that information as well (in the MIB modules).
  
- I wonder if      alarmItuTc MODULE-IDENTITY
  would not be better (and more in line with the rest of the naming)
                   ituAlarmTc MODULE-IDENTITY
- In the ITU-ALARM-TC module, I see references in the TC DESCRIPTION
  clauses. Would it not be better to use a REFERENCE clause?
- In the ITU-ALARM-MIB I see references in the various DESCRIPTION
  clauses. Would it not be better to use a REFERENCE clause?

Thanks,
Bert

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 16 Mar 2003 22:41:10 -0800

Hi -

WG chair hat on:  Ok, we'll spin another draft to address these comments.
Sharon and Dan: please review these before the WG session to identify
any that might require discussion there.  These all seem like reasonable
comments,  but I might be missing something.

There were a couple of "wish list" items in the latest SG 4 liaison.  I don't
think this would be a good time to try to fold them into this revision, but
I'm willing to listen to other opinions.

Kam, An-ni, and Dave: please double-check the ARC draft
<draft-ietf-disman-conditionmib-06.txt>  I think several of
these comments apply to that document as well.

Both editing teams:  when will the updates be ready?

Randy

> From: "Wijnen, Bert (Bert)" <[email-masked]>
> To: "Disman (E-mail) (E-mail)" <[email-masked]>
> Sent: Saturday, March 15, 2003 12:38 PM
> Subject: [Disman] AD review of: draft-ietf-disman-alarm-mib-09.txt
>