Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 29 Sep 2003 10:34:13 -0400

Hi

Depending on how long the usual spelling, grammar and syntax checks take,
this update will be sent in either today or tomorrow.

I've grouped the comments from Randy into 5 categories below
	- Changed
		- I made these changes to the document
	- RFC Editor
		- These were things that I felt the RFC was in a better
position to consider
	- Closed Design Issues
		- Items which had previously been discussed by the wg 
	- Non-Changes
  		- Items that Randy was making more an observation than
recommending a change
	- Other 

Changed
------

1) Page 1: "Avaya Inc" should probably be "Avaya Inc."
since that's how the company refers to itself on its
website.

3) Page 3: "monitoring large number of entities" ->
   "monitoring large numbers of entities"
4) Page 3: "high-reliability" -> "high reliability"

5) Page 3: "accurately determine problems that may have occurred when" ->
    "accurately identify problems that may have occurred while" or
    "accurately determine whether problems have occurred while"

6) Page 3: "on the entity and even after" ->
           "on the entity.  Even after"

8) Page 3: "This memo describes a method of using alarm management in SNMP
to
   address these problems. It also provides the necessary MIB objects
   to support these methods." change "a method" to "methods" or change
   "these methods" to "this method".

9) Page 3: "alarms management" -> "alarm management"

10) Page 4: "of interest to a management station" ->
    "of interest".  (one does not need a management
    station for events to be meaningful and useful,
    particularly in a disman context.)

12) Page 4: "ITU" acronym should be expanded, for
    "ITU model" a reference should be given.

17) Page 6: "OID" acronym should be expanded

18) Page 6: "offset, value pair" -> "(offset, value) pair"

19) Section 3.3.2, third paragraph, first sentence:
    "identify" -> "specify",
    and "define" -> "identify"

21) Page 6: "Notifications, use" -> "Notifications use"

22) Page 6: "These alarm states would be entered by some internal stimuli"
    This is literally wrong.  "entered" -> "triggered" would make
    much more sense.

22) Page 6: both occurrences of "indicated in the SNMP-TARGET-MIB"
    should be amended to include "SNMP-NOTIFICATION-MIB".  Otherwise
    it's just plain wrong.

23) Page 6: "by some internal stimuli" -> "by some internal stimulus"
    (though it would probably be more correct to say "by some
    stimulus outside the scope of this memo")

25) (global) be consistent: "ITU Alarm MIB" or "ITU-ALARM-MIB".

27) Section 3.7 "Notification log MIB" -> Notification Log MIB"
    (and elsewhere)

29) Page 10: "other state transition relationship between" ->
    "other state transition relationships between"

30) Page 10: "alarmModelIndex acts as a unique" ->
    "The alarmModelIndex acts as a unique"

31) Page 10: "consists of defining the" ->
    "consists of definitions of the"

32) Page 10: "that is sent out when an alarm changes state"
    The notification may be generated, but whether it is
    actually sent out (on the wire) is another matter.  For
    example, it might be logged locally but *not* forwarded to
    a management station.

33) Section 4.1.1: one consequence of this approach is that
    one cannot use multiple extensions for a single alarm.
    So, for example, one couldn't make an extension to the
    ITU Alarm MIB and have it work using the method described here.
    This may be the intent, but it would be good to be explicit about it.

35) Section 4.1.3: (see comment 14 above) this paragraph doesn't
    tell the whole story of what a manager needs to do to get
    these notifications.  The sentence beginning with "alternatively"
    only makes things worse, since it will result in a configuration
    that is contrary to the goal in the paragraph's topic sentence.

36) Page 11: "interface for example" -> "interface, for example"

37) page 12: "interested in resource type" ->
    "interested in a resource type"

38) Page 12 (A) (and (B, C) on page 13) should include references
    for these (copied) notification type definitions.

40) 4.1.5: "the manager" -> "managers"

41) 4.1.6: "and, optionally" -> "and, optionally,"

42) 4.1.7: "therefore," -> ""

43) page 15 (ResourceId):  I agree with the intent of the last
    sentence in the description, but if there is a MUST requirement
    here, how do we ensure that implementations know what to choose
    for any arbitrary table?

Sharon -> I added this, but I probably should not have. I guess we can
consider it clarifying editorial in nature. 

45) page 16: "zero lengths string" -> "zero-length string"

48) alarmModelNotificationId should have a DEFVAL of { 0 0 }

49) alarmModelRowStatus should spell out that the
    alarmModelVarbindIndex and alarmModelVarbindValue
    MUST be set before row can go active.

Sharon-> I've fixed this another way.

50) alarmModelDescription should have a DEFVAL of ""

51) alarmModelSpecificPointer should have a DEFVAL of { 0 0 }
    DESCRIPTION should specify what it means of the referenced
    row does not exist.

52) alarmModelVarbindSubtree should have a DEFVAL of { 0 0 }

53) alarmModelResourcePrefix should have a DEFVAL of { 0 0 }

54) page 19: "RFC2579" -> "RFC2579."

55) alarmModelRowStatus does not permit modification of a
    model while active alarms exist.  This would seem to create
    the possibility of "un-throttle-able" alarm storms, contrary
    to the spirit of draft-ietf-ops-mib-review-guidelines-01.txt
    section 4.7 last paragraph.

58) alarmActiveEngineAddress: "IP Address" -> "address"
    ditto alarmClearEngineAddress

59) alarmActiveContextName: this is defined to be an SnmpAdminString.
    This is fine for the case where its value is a context name.
    However, in the case where it is a community, provision needs
    to be made for the possibility that the community name would not
    be a well-formed SnmpAdminString.  (for example, 0xFF would be
    a legal community, but would violate the rules for UTF-8.)
    ditto alarmClearContextName

61) page 25: "is used" -> "is used for a given row in this table"

63) alarmActiveState, alarmClearState: the names for these notifications
    aren't terribly good. more importantly, something needs to be said
    about throttling per draft-ietf-ops-mib-review-guidelines-01.txt
    section 4.7 last paragraph, perhaps simply to the effect that these
    are "second order" notifications that rely on lower-level throttling
    and filter specification.

Sharon->I did this more in line with the examples in the review guidelines.

65) 5.1: "about alarms" -> "about alarms modeled using the ituAlarmTable"
    "total alarms" -> "total alarms modeled using the ituAlarmTable"

66) 5.2: we will probably need to give IANA more guidance on how additions
    should be approved.  We agreed that we didn't want an immortal WG, but
    we do need to tell them what kind of review, if any, is needed before
    a addition is made.

67) Page 45: '" Represents' -> '"Represents'

69-2) The table[ituAlarmEntry] should probably say something about
persistence as well.

74) section 6.1 should have a reference for the notification type
    definitions

75-3)It should also note that alarm clearing
(alarmClearMaximum) could cause retained security alarm information (for
example) to be lost.  

RFC Editor
----------
2) the FF character is merged with the header lines,
resulting in many too-long lines.  The RFC editor can
fix these.

7) Page 3: "be able to determine current problems on a system" ->
           "be able to determine what the current problems on a system are"

13) Page 4: formatting of "Alarm State" paragraph is odd;
    there is a premature line break after "also".

15a) (global) The document is inconsistent in its use of space
    after period at the end of a sentence.  There should
    consistently be two spaces after each period ending a sentence.

16) (global) "modelling" -> "modeling",
    "modelled" -> "modeled"
    "behaviour" -> "behavior"
    A spelling check would be advisable to extirpate the briticisms.

Closed Design Issue
-------------------

11) Page 4: "transmissions of management" ->
    "transmission of management"  (I personally think that
    defining "notification" in terms of transmission is a
    mistake, but it's too late to re-hash that discussion.)

14) Page 4: "A notification SHOULD be sent on alarm raise."
    Given the definition of notification, and the role of RFC
    3413, this sentence should be deleted.  Whether a notification
    should be sent depends on whether some manager is interested
    in it and has configured the SNMP-NOTIFICATION-MIB and
    SNMP-TARGET-MIB accordingly.

Sharon -> This was explicitly discussed and wg consensus was that it was OK
to indicate a preference for sending notifications.

15b) Page 4: "A notification SHOULD be sent on alarm clear."
    Delete this sentence, same rationale as (14) above.

24) Section 3.3.3: the first sentence is a bit hard to swallow:
    as a practical matter, to find out which notifications are
    not of interest, one would have to walk the alarm model table
    to find out what *is* of interest, and then remove that set
    from the set of all possible notifications, which isn't listed
    in any convenient spot.

26) Section 3.3.5: "Solutions interested in being able to differentiate the
   source of the alarm by means other than the source IP address and
   resource ID"  is at odds with what's actually done in the
   alarmActiveEntry and alarmClearEntry.  Both include information
   for the LocalSnmpEngineOrZeroLenStr, AddressType, EngineAddress,
   and ContextName.

28) Section 3.7: "This format allows for the storage of any Trap
    or Notification that can be defined using SMIv1 or SMIv2."
    Not quite consistent with definition of "Notification";
    suggest "instance of any TRAP-TYPE or NOTIFICATION-TYPE",
    though I think talking about SMIv1 and SMIv2 isn't helpful here.
    See #47 below.

Sharon-> I actually meant the SMI.

39) 4.1.5: "table can, and probably should, be" ->
    "table MAY be".  I don't think we had consensus
    to make this a SHOULD, but I'm open to the possibility.

47) (alarmModelVarbindIndex) (also alarmActiveVariableEntry)
I repeat my comments from May, since they're still not reflected in the
draft:

> The words that are there now seem to be backwards from what I thought 
> was agreed: since RFC 3416 is Standard, and 1157 is Historic, that the 
> numbering should start with 1 for the SysUptime, which would be the 
> value extracted from elsewhere in the PDU in the case of a SNMPv1 
> trap.  What's there now (still) seems unnecessarily confusing.
>
> Note that Harrie Hazewinkel's message of March 18, 2003 also has 
> concerns with this same paragraph.
>
> The discussion back in April 22, 2002 went the same way, and Sharon's 
> post of June 3, 2002 gave the resolution of issue #38 as being to 
> treat everything "v2-style".

Sharon-> See Section 3.6 of the document

56) alarmListName's DESCRIPTION should spell how this object's
    value hooks into the SNMP-NOTIFICATION-MIB.  Without out this
    bit of explanation, the whole thing is magic.

60) alarmActiveLogPointer: should spell out that the log's name
    would be the same as alarmListName for this instance.
    ditto alarmClearLogIndex

75-1) Section 7 should describe the need for security administrators to
configure a coherent VACM policy for the configuration of the
SNMP-NOTIFICATION-MIB, the log MIB, and these MIBs based on log name.  

Sharon->We agreed back when everyone was complaining about the
Sharon->notification log MIB to not tie this document to it. The goal 
Sharon->was to be able to support it and any other log.

64) alarmCompliance: is having so many unconditionally optional groups
    a good idea, particularly in light of RFC 2026 section 4.1.2 paragraph
two?

68) ituAlarmGenericModel: why is this object needed? the indexing
    information needed to find the model entry is the same for both
    tables.

69-1) ituAlarmEntry: the DESCRIPTION needs to say something about how
    rows in this table come into existence.  Currently, it looks like
    immaculate conception.  If these things are created under management
    control, then I'd strongly suggest DEFVALs for
ituAlarmPerceivedSeverity,
    ituAlarmEventType, ituAlarmProbableCause, and ituAlarmAdditionalText.

73) ituAlarmCompliance: see comment #64.

75-4) I missed anything like an "alarmActiveMaximum", yet the document
doesn't seem to describe what should happen if there are too many active
alarms, as might happen if there are lots of instances of a particular type
of resource, and an administrator inadvertently specifies a frequent,
innocuous event as being of interest.

Sharon->The design was normal table wrapping

Non-changes
------------

20) Section 3.3.2, third paragraph: the phrase
    "when the entity generated a Notification"
    isn't right, given the way "notification"
    is defined.  However, if it doesn't confuse anyone,
    I guess we can leave it the way it is.

29) withdrawn

34) Section 4.1.2: alarmModelDescription might get some grief from
    internationalization experts (see RFC 2130), but this was hashed
    out in the WG.

Other (Resolved)
------

44) page 15 (LocalSnmpEngineOrZeroLenStr): where the DESCRIPTION
    talks about "instantiation" doesn't make sense.  I think it's
    referring to use of the TC in an OBJECT-TYPE definition, rather
    than object instantiation.

Sharon -> This seems more a wordsmith thing.

46) page 16 (alarmModelLastChanged) I think this would be more
    robust if it were a persistent DateAndTime rather than
    TimeTicks, using the "0000...." convention for virginal
    value, particularly given the persistence requirements of
    the table.

Sharon-> Too late to change data types. Keep in mind it is good practice
Sharon-> to rediscover the box after it is rebooted. I think we say 
Sharon-> stuff along these lines in the ID.

57) alarmActiveEngineID: the phrase "alarms from only one
    engine" isn't quite what I though we meant to accomplish.
    Wouldn't "only local alarms" be more to the point?
    Same goes for alarmClearEngineID

Sharon-> "Local" is too ambiguous.

62) alarmActiveStatsActives, the SYNTAX says this is a Counter32,
    but the DESCRIPTION sure makes it sound like it's supposed to
    be zero-based.

71) ituAlarmActiveStatsIndeterminates,
    ituAlarmActiveStatsCriticals,
    ituAlarmActiveStatsMajors,
    ituAlarmActiveStatsMinors, and
    ituAlarmActiveStatsWarnings are all Counter32, but their
    DESCRIPTIONs sound like they're assumed to be zero-based.

Sharon-> Counter32 can have a value of 0.

70) ituAlarmActiveDetector, ituAlarmActiveServiceProvider, and
    ituAlarmActiveServiceUser need better DESCRIPTIONs.  I think
    it needs to be more explicit that their values are the names
    of the object instances corresponding to these resources.

72) The DESCRIPTION of ituAlarmServiceUserGroup isn't helpful.

Sharon->These are the descriptions used in the ITU. It would be a new 
Sharon->design item to provide 'improved' descriptions.

75-2) This section should also mention throttling / DoS attacks based on
notification generation. 

Sharon->Neither of the examples given in the MIB Review Guidelines do

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 29 Sep 2003 10:34:13 -0400

Hi

Changed
------

RFC Editor
----------

Closed Design Issue
-------------------

Non-changes
------------

29) withdrawn

Other (Resolved)
------

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada