[Note]: 'The revision 17 has been submitted, but is not yet at internet-drafts repository. FOr now, it can be accessed at http://www.psg.com/~bwijnen/draft-ietf-disman-alarm-mib-17.txt' has been cleared by Bert Wijnen

[Ballot comment]
Typo in the IANA Considerations --

"Values of IANAProbableCause greater than 1024" should be IANAItuProbableCause

As far as allowing the ones over 1024 to be assigned FCFS, is this a good idea?  What if ITU assigns them in a future document?

[Ballot comment]
In the Terminology section, the draft says:

  Alarm Clear
    The detection that the fault indicated by an alarm no longer
    exists.  A Notification SHOULD be sent on alarm clear.

I'm a bit concerned about imposing a  requirement like this in the
terminology section.  Is a better place to impose this available?

In Section 3.4, the draft says:

  Security for alarms is awkward since access control for the objects
  in the underlying Notifications can be checked only where the
  Notification is created.  Thus such checking is possible only for
  locally generated Notifications, and even then only when security
  credentials are available.

This is very hard to parse, since it is difficult to understand whether
the kind of security we're talking about is access control for the
alarms themselves, access control to which Notifications refer,
or something.  It would help me, I think, if it said "for this $THREAT,
there are the following issues".

[Note]: 'The revision 17 has been submitted, but is not yet at internet-drafts repository. FOr now, it can be accessed at http://www.psg.com/~bwijnen/draft-ietf-disman-alarm-mib-17.txt' added by Bert Wijnen

Revision 13 still has some issues:

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: donderdag 5 juni 2003 15:22
To: Dan Romascanu (E-mail); Sharon Chisholm (E-mail)
Cc: Randy Presuhn (E-mail); Wijnen, Bert (Bert)
Subject: RE: I-D ACTION:draft-ietf-disman-alarm-mib-13.txt

You guys keep confusing me...  I now checked revision 13

I see:
- citations to RFC1905, while you have (correctly) changed
  the entry in the references section to RFC3416. Of course
  the citation should be in sync
- I now see:
  LocalSnmpEngineOrZeroLenStr ::= TEXTUAL-CONVENTION
      STATUS current
      DESCRIPTION
              "An SNMP Engine ID or a zero length string. The
              instantiation of this object will provide guidance
              on when this will be an SNMP Engine ID and when it
              will be a zero lengths string"
      SYNTAX        OCTET STRING (SIZE(1..32))
  Which is an improvement over the earlier OBJECT-IDENTIFIER,
  but you exlude zero as a possible size and yet the description
  clause indocates that zero length string sis OK.
  I had suggested that the best SYNTAX would be:
      SYNTAX    OCTET STRING (SIZE (0 | 5..32))
  Since lengths of 1,2,3,4 are not valid EngineIDs either

- You have citations to RFC2576, but it is not in the References
  section. By the way, I expect the follow up of coex to be
  approved by IEESG this coming Thursday.

New things I saw:
- RFC2037 has been obsoleted by RFC2737... would it be better to
  refrence newer RFC?
- PrinterMib has just been approved to obsolete RFC1759
  draft-ietf-printmib-mib-info-15.txt. You may want to consider
  to reference new RFC-to-be (it is in RFC-Editor queue) instead.
  If so, pls check, cause object definitions have changed a bit.

Thanks,
Bert

Revision 12 still has several nits.
And at least 2 things that are trouble:

It has quite a few non-ASCII characters. See below output of checkpage.
Most are at page breaks (which also I think) cuases the 73 char lines
A few of them are in the alarm MIB:
      alarmGroups OBJECT IDENTIFIER ::= { alarmConformance 2 }xE1
              alarmActiveVariableOpaqueValxE1 xE1
So cause syntax errors

I am also surprised by (a fix that you made on my request):
  LocalSnmpEngineOrZeroLenStr ::= TEXTUAL-CONVENTION
      STATUS current
      DESCRIPTION
              "An SNMP Engine ID or a zero length string. The
              instantiation of this object will provide guidance
              on when this will be an SNMP Engine ID and when it
              will be a zero lengths string"
      SYNTAX        OBJECT IDENTIFIER
Should that not be a OCTET STRING ?? And to be precize:
      SYNTAX    OCTET STRING (SIZE (0 | 5..32))

Full set of comments below.
-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: dinsdag 6 mei 2003 16:44
To: Dan Romascanu (E-mail); Sharon Chisholm (E-mail)
Cc: Randy Presuhn (E-mail)
Subject: FW: I-D ACTION:draft-ietf-disman-alarm-mib-12.txt

So I checked this new revision....
Mmm.... sending to you first instead of disman list.

It has quite a few non-ASCII characters. See below output of checkpage.
Most are at page breaks (which also I think) cuases the 73 char lines
A few of them are in the alarm MIB:
      alarmGroups OBJECT IDENTIFIER ::= { alarmConformance 2 }xE1
              alarmActiveVariableOpaqueValxE1 xE1
So cause syntax errors

I am also surprised by (a fix that you made on my request):
  LocalSnmpEngineOrZeroLenStr ::= TEXTUAL-CONVENTION
      STATUS current
      DESCRIPTION
              "An SNMP Engine ID or a zero length string. The
              instantiation of this object will provide guidance
              on when this will be an SNMP Engine ID and when it
              will be a zero lengths string"
      SYNTAX        OBJECT IDENTIFIER
Should that not be a OCTET STRING ?? And to be precize:
      SYNTAX    OCTET STRING (SIZE (0 | 5..32))

I still see (useless) references to old MIB-boilerplate docuemnts
in the (normative) references section. Namely... do we need:
[RFC1155], [RFC1157], [RFC1212], [RFC1215], [RFC1901], [RFC1906]

I also still see refrences to [RFC1905], which I think should be
to [RFC3416].

In the Informative references I see a ref to [RFC2233]. Should that not
be [RFC2863] ??

The copyright statement on Page35 now reeads:
              Copyright (C) The Internet Society 2003."
I had posted to the mibs@ops.ietf.org (4th of april, so after you
posted your revision I suspect, but given the other comments I have
I might as well add this) that it should be:
      Copyright (C) The Internet Society (year).  The
      initial version of this MIB module was published
      in RFC xxxx. For full legal notices see the RFC
      itself or see:  http://www.ietf.org/copyrights/ianamib.html

Also, Dan had suggested to add some explanatory text which I do not
yet see, see his email below.

Did I not also question the fact that you have [RFCxxxx] and [MMMM.3100]
and [X.733] references in DESCRIPTION clauses of objects? The problem
(minor) I see is that if they MIB module gets extracted from the doc, then
those references/citations are no longer valid. I tend to suggest to people
to use (RFCxxxx) instead of [RFCxxxx].  A nit I guess.
In many cases however, such thing probably warrant a REFERENCE clause, no?

My SMICng run still says:

  C:?wijnensmicngwork>smicng alarm.inc
  W: f(alarm.mi2), (620,19) Item "alarmActiveVariableOctetStringVal"
    should have SIZE specified
Would it be too much to add a SIZE (0..65535) ??

  W: f(alarm.mi2), (651,4) SMIv2 discourages used of Opaque for SYNTAX
    value of "alarmActiveVariableOpaqueVal"
We can ignore that

  W: f(alarm.mi2), (652,19) Item "alarmActiveVariableOpaqueVal" should
    have SIZE specified
Would it be too much to add a SIZE (0..65535) ??

  W: f(alarm.mi2), (530,33) Row "alarmActiveVariableEntry" does not
    have a consistent indexing scheme - index items must be in same
    order as used in INDEX clause for "base row" alarmActiveEntry
Even with Dan's explanatory text, it looks weird.
But if the others think it is OK, I will accept.
I am surprised that Perkins did not jump on it earlier.

  W: f(alarm.mi2), (983,8) OBJECT-GROUP "alarmActiveStatsGroup" is
    not used in a MODULE-COMPLIANCE in current module
  W: f(alarm.mi2), (995,4) OBJECT-GROUP "alarmClearGroup" is not
    used in a MODULE-COMPLIANCE in current module
  W: f(alarm.mi2), (1012,4) NOTIFICATION-GROUP "alarmNotificationsGroup"
    is not used in a MODULE-COMPLIANCE in current module
I think our MIB Doctor Review Guidelines RECOMMEND to list them and
explain in the DESCRIPTION clause that they are optional,
see sect 4.8 of draft-ietf-ops-mib-review-guidelines-01.txt
  *** 0 errors and 7 warnings in parsing

  W: f(itualarm.mi2), (360,4) OBJECT-GROUP "ituAlarmServiceUserGroup"
    is not used in a MODULE-COMPLIANCE in current module
  W: f(itualarm.mi2), (370,4) OBJECT-GROUP "ituAlarmSecurityGroup"
    is not used in a MODULE-COMPLIANCE in current module
  W: f(itualarm.mi2), (381,4) OBJECT-GROUP "ituAlarmStatisticsGroup"
    is not used in a MODULE-COMPLIANCE in current module

I think our MIB Doctor Review Guidelines RECOMMEND to list them and
explain in the DESCRIPTION clause that they are optional,
see sect 4.8 of draft-ietf-ops-mib-review-guidelines-01.txt

Thanks,
Bert
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: maandag 28 april 2003 18:24
To: Wijnen, Bert (Bert); Sharon Chisholm; Randy Presuhn
Subject: RE: [Disman] Re: draft-ietf-disman-alarm-mib-11.txt

Sure.

In the DESCRIPTION clause of alarmActiveDateAndTime I suggest that we add:

'This index serves the purpose of helping applications retrieve active entries entered after a certain moment in time.'

In the DESCRIPTION clause of alarmActiveVariableEntry, add after the first phrase:

'Entries in the alarmActiveTable are uniquely identified by alarmListname and alarmActiveIndex.'

Sharon, if you are OK with this, please add to your revision.

Dan
------------ Bert Wijnen ran: checkpage.awk and it tells us:

Long page at 59
Bad chars at 60
Long line at 60 with 73 chars
Bad chars at 118
Long line at 118 with 73 chars
Bad chars at 176
Long line at 176 with 73 chars
Bad chars at 234
Long line at 234 with 73 chars
Bad chars at 292
Long line at 292 with 73 chars
Bad chars at 350
Long line at 350 with 73 chars
Bad chars at 408
Long line at 408 with 73 chars
Bad chars at 466
Long line at 466 with 73 chars
Bad chars at 524
Long line at 524 with 73 chars
Bad chars at 582
Long line at 582 with 73 chars
Bad chars at 640
Long line at 640 with 73 chars
Bad chars at 698
Long line at 698 with 73 chars
Bad chars at 756
Long line at 756 with 73 chars
Bad chars at 814
Long line at 814 with 73 chars
Bad chars at 872
Long line at 872 with 73 chars
Bad chars at 930
Long line at 930 with 73 chars
Bad chars at 988
Long line at 988 with 73 chars
Bad chars at 1046
Long line at 1046 with 73 chars
Bad chars at 1104
Long line at 1104 with 73 chars
Bad chars at 1162
Long line at 1162 with 73 chars
Bad chars at 1220
Long line at 1220 with 73 chars
Bad chars at 1278
Long line at 1278 with 73 chars
Bad chars at 1336
Long line at 1336 with 73 chars
Bad chars at 1394
Long line at 1394 with 73 chars
Bad chars at 1452
Long line at 1452 with 73 chars
Bad chars at 1510
Long line at 1510 with 73 chars
Bad chars at 1568
Long line at 1568 with 73 chars
Bad chars at 1626
Long line at 1626 with 73 chars
Bad chars at 1684
Long line at 1684 with 73 chars
Bad chars at 1742
Long line at 1742 with 73 chars
Bad chars at 1800
Long line at 1800 with 73 chars
Bad chars at 1815
Bad chars at 1858
Long line at 1858 with 73 chars
Bad chars at 1865
Bad chars at 1916
Long line at 1916 with 73 chars
Bad chars at 1974
Long line at 1974 with 73 chars
Bad chars at 2032
Long line at 2032 with 73 chars
Bad chars at 2090
Long line at 2090 with 73 chars
Bad chars at 2148
Long line at 2148 with 73 chars
Bad chars at 2206
Long line at 2206 with 73 chars
Bad chars at 2264
Long line at 2264 with 73 chars
Bad chars at 2322
Long line at 2322 with 73 chars
Bad chars at 2380
Long line at 2380 with 73 chars
Bad chars at 2438
Long line at 2438 with 73 chars
Bad chars at 2496
Long line at 2496 with 73 chars
Bad chars at 2554
Long line at 2554 with 73 chars
Bad chars at 2612
Long line at 2612 with 73 chars
Bad chars at 2670
Long line at 2670 with 73 chars
Bad chars at 2728
Long line at 2728 with 73 chars
Bad chars at 2786
Long line at 2786 with 73 chars
Bad chars at 2844
Long line at 2844 with 73 chars
Bad chars at 2902
Long line at 2902 with 73 chars
Bad chars at 2960
Long line at 2960 with 73 chars
Bad chars at 3018
Long line at 3018 with 73 chars
Bad chars at 3076
Long line at 3076 with 73 chars
Bad chars at 3134
Long line at 3134 with 73 chars
Bad chars at 3192
Long line at 3192 with 73 chars
Bad chars at 3250
Long line at 3250 with 73 chars
Bad chars at 3308
Long line at 3308 with 73 chars
Bad chars at 3366
Long line at 3366 with 73 chars
Bad chars at 3424
Long line at 3424 with 73 chars
Bad chars at 3482
Long line at 3482 with 73 chars
Bad chars at 3540
Long line at 3540 with 73 chars
Bad chars at 3598
Long line at 3598 with 73 chars
Bad chars at 3656
Long line at 3656 with 73 chars
Bad chars at 3714
Long line at 3714 with 73 chars
-: 66 lines containing non-US-ASCII characters
-: 64 lines longer than 72 characters, max 73
-: 1 pages longer than 58 lines, max 3771 lines

WG chairs asked WG for possible comment on the new revision before putting it  back on AD plate.
The WG needs to respond by April 14th

AD review comments posted to the WG list:
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: zaterdag 15 maart 2003 21:38
To: Disman (E-mail) (E-mail)
Subject: [Disman] AD review of: draft-ietf-disman-alarm-mib-09.txt

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