Subject: Fwd: Notification Log MIB review

From: Randy Presuhn <[email-masked]>
Date: Wed, 13 Oct 1999 13:01:58 -0700 (PDT)

Hi -

fwd fyi.

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com/
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's is probably coincidental.
 ------------------------------------------------------------------------

> From [email-masked] Wed Oct 13 12:09:28 PDT 1999
> From: "Harrington, David" <[email-masked]>
> To: "Randy Presuhn (E-mail)" <[email-masked]>,
>         "Bert Wijnen (E-mail)" <[email-masked]>
> Subject: Notification Log MIB review
> Date: Wed, 13 Oct 1999 15:03:02 -0400
> 
> This message is in MIME format. Since your mail reader does not understand
> this format, some or all of this message may not be legible.
> 
> ------_=_NextPart_000_01BF15AD.A2F6A7A4
> Content-Type: text/plain;
> 	charset="ISO-8859-1"
> 
> Hi,
> 
> Attached is my review of the Notification Log MIB.
> 
> ------------------------------------------------------------
> #include <std.disclaimer> 
> David Harrington
> [email-masked] 
> Spectrum Smart Networking
> Cabletron Systems Inc. 
> 
> 
> ------_=_NextPart_000_01BF15AD.A2F6A7A4
> Content-Type: text/plain;
> 	name="notifyMibreview.txt"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: attachment;
> 	filename="notifyMibreview.txt"
> 
> To: Randy Presuhn
> CC: Bert Wijnen
> From: Dave Harrington
> Re: review of notify mib
> date: 10-13-99
> 
> General:
> 1) "may" and "may not" are used in a number of places in text. Some =
> should be MAY or SHALL. Can you (or the new editor) double check them? =
> Please double check all uses of the rfc2119 words.
> 2) please double check the 70-character limit. See =
> nlmConfigLogFiltername and globalEntryLimit for examples.
> 
> 
> 1. Abstract - "experimental" needs to be changed
> 3. Overview - "(to consider SNMPv1, see [RFC1903]) - I don't understand =
> this statement.
> 3. "or to" maybe should be "if they";=20
> 	I think "know" should be "determine".
> 3.1.1. "combine information from multiple engines"=20
> 	I would add ",such as is in a mid-level manager," for clarity
> 3.1.2. "A managed system with fewer resources may not allow" - use =
> "MAY"
> 	(it might be less ambiguous to change the wording since "may not" =
> could be construed as "MUST NOT", rather than as "may disallow"
> 3.1.2. "the managed system does not apply access control ..." should =
> does be strengthed with an rfc2119 word?
> 3.2.3. RMON2's TimeFilter provides similar functionality, and it =
> appears to be getting widely used in new mibs. Was it considered here?
> 	That suggestion can of course be considered after this review.
> 
> The MIB:
> IMPORTS - "experimental" not needed
> CONTACT-INFO ???
> {experimental xx } -> { mib-2 xx } as per bert
> import mib-2
> get an IANA placement
> 
> GlobalEntryLimit - why read-write? why not just agent controlled?
> 	please add warning about NMS contention for this limit, and the impact =
> of discarding oldest to other NMSs who may not have seen them yet. Is =
> this a potential denial of service attack?
> 
> GlobalAgeOut - If an application changes the time .. older than the =
> time... seems slightly incorrect. I think using "value is less =
> ambiguous than "time".
> 
> nlmConfigLogEntryLimit sets an individual log's limit. Must the total =
> of all nlmConfigLogEntryLimit values be less than GlobalEntryLimit, or =
> can the sum of LogEntryLimits exceed the GlobalEntryLimit? under that =
> condition, SHALL/MAY/might one or more individual logs  be restricted =
> to less than the specified LogEntryLimit? Since these are read-write, =
> could this be used to cause denial of service (or preferential =
> treatment)?
> 
> AdminStatus - please comment on NMS contention. (Recurring theme; Maybe =
> this should be done in overview or security considerations).
> 
> EntryStatus - wouldn't this be more obviously a RowStatus if named =
> nlmConfigLogRowStatus?
> 	Since this description says that the system should record the =
> credentials, shouldn't we put a warning here to protect those =
> credentials? (I'm sure somebody will think they should be added to the =
> row, and will make them accessible via snmp, before they get fired).
> 
> NotificationsBumped - we don't include the AgeOuts. I am concerned =
> about NMS contention and the ability of a rogue NMS (or a rogue =
> operator) to deny service to another NMS (or another operator) by =
> deliberately setting AgeOut or EntryLimits to 0, then back to some =
> other value. An NMS could read the log, then wipe the log clean, =
> denying another NMS from getting the deleted rows, including such =
> things as authorization and access-denied warnings.
> 
> nlmLogTable description - maybe we should have WHATEVER added to =
> rfc2119? How does this WHATEVER attitude impact interoperability? how =
> would it likely impact correlation of notifications by an NMS managing =
> multiple devices? Why not just pick one behavior or the other? How =
> about a RECOMMENDED rather than a "one would expect"?
> 	- nlmLogTime for entries before the reset **MUST be** set to 0.
> 
> LogEntry discusses discarding the oldest log in ANY log if =
> GlobalEntryLimit is exceeded. I think this belongs under =
> GlobalEntryLimit as well. It is an important constraint that could =
> affect choices during implementation.
> 
> LogIndex - what exactly does "flush existing entries" mean? The whole =
> log MAY be discarded? Or does this refer to flushing aged-out entries? =
> Can this be tightened up to improve interoperability? What should an =
> NMS expect from a managed system?
> =09
> EngineID - is there any way to preserve the address?
> 
> NotificationID - what to do for v1 traps?
>  	identifer s/b identifier
> 
> LogVariableEntries - should this be fate-sharing with LogTable? It =
> isn't discussed. One would expect an rfc2119 word somewhere here.
> 
> ValueType - I think rfc2119 is called for here. Otherwise some bright =
> implementor will use the unused objects for passing error codes or =
> something. This shouldn't, but could, confuse an NMS. ;-)
> 
> In the compliances:
> EntryStatus uses "may not" which is ambiguous. please change all uses =
> of "may" and "may not" and "not allow" to comply with rfc2119.=20
> 
> GROUP DateGroup: is that "SHALL NOT be implemented on systems that do =
> not", or is it optional? Note that optional could cause =
> interoperability  and correlation issues. Just to be absolutely =
> unambiguous, "implemented on system that do not keep wall clock date =
> and time." to be sure it cannot be read "... not implemented on systems =
> that do not implement it."
> 
> Security Considerations - this is accurate, but I'm not sure it will =
> meet IESG acceptance. This small section is easily overlooked, and =
> there are severe security considerations in this spec. Bert?
> 
> Author's Address - I guess another one is needed here.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ------_=_NextPart_000_01BF15AD.A2F6A7A4--
>

---

From: Ram Kavasseri <[email-masked]>
Date: Wed, 13 Oct 1999 14:28:54 -0700

David,

I'm currently making edits to the Notification Log MIB. Since I'm trying to catch up and respond to previous comments, it will take a day or two before I can respond to this. I hope that's ok.

Ram Kavasseri