Subject: Fwd: Responses to comments on the NOTIFICATIOn-LOG-MIB

From: Randy Presuhn <[email-masked]>
Date: Mon, 18 Oct 1999 10:42:06 -0700 (PDT)

Hi -

It's a first!  A legitimate post from a list subscriber intercepted
by the spam filters.  (The /[M][L][M]/ filter catches a LOT of trash.
I suggest that folks avoild that abbreviation in these discussions.)

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

> Received: from tangelo.bmc.com ([email-masked] [172.17.7.166])
> 	by dorothy.peer.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id QAA14033
> 	for <[email-masked]>; Sun, 17 Oct 1999 16:10:12 -0700 (PDT)
> Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250])
> 	by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id SAA09812
> 	for <[email-masked]>; Sun, 17 Oct 1999 18:10:15 -0500 (CDT)
> Received: from ramk-pc2.cisco.com (ramk-dsl3.cisco.com [10.19.11.156])
> 	by sigma.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id QAA26286
> 	for <[email-masked]>; Sun, 17 Oct 1999 16:10:01 -0700 (PDT)
> Message-Id: <[email-masked]>
> X-Sender: [email-masked]
> X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
> Date: Sun, 17 Oct 1999 16:01:16 -0700
> To: [email-masked]
> From: Ramanathan Kavasseri <[email-masked]>
> Subject: Responses to comments on the NOTIFICATIOn-LOG-MIB
> Mime-Version: 1.0
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: 8bit
> X-MIME-Autoconverted: from quoted-printable to 8bit by dorothy.peer.com id QAA14034
> 
> 
> Hi,
> 
> Bob Stewart asked me to take over the editing of the Notification Log MIB,
> Expression MIB and the Event MIB. This is my first time editing working-group
> drafts, so if you have any pointers on procedures or any tips you feel are
> useful, please do send them my way. 
> :-)
> 
> I've collected review comments from Bert Wijnen, David Harrington and Sharon
> Chisholm, and have added my responses to them below. If you'd prefer that I
> maintained the original threads, please let me know, and I'll do that.
> 
> Please find my comments marked with a [*].
> 
> The following are my responses to Bert’s comments:
> 
> > 1. Root the mib under mib-2 xx, do import mib-2 and do not import
> > experimental.
> 
> [*] ok.
> 
> > 2.    Pls add a REVISION clause similar to the other 2 mibs.
> 
> [*] Didn’t follow what was needed here… Looked at the Expression and Event
> MIBs, but couldn’t figure out what Bert had indicated.
> 
> > 3. Same comment/question on IPR section, as for other 2 mibs.
> 
> [*] Looked at the thread on the xpression MIB - came up blank on what Bert
> meant. Will ask him for clarifications on this.
> 
> > 4. I would prefer that section 7 explicitly points to sect 3.1.2 instead of
> > "overview"
> 
> [*] Ok. Will change from:  
> “Security issues are discussed in the overview.” 
> to
>                 “Security issues are discussed in Section 3.1.2”.
> 
> > 5. I thought we agreed to name this mib DISMAN-NOTIFICATION-LOG-MIB ??
> 
> [*] As I emailed to the Disman mailing list, I feel this MIB will be
> implemented by non-M L M device,
> so the name “DISMAN-NOTIFICATION-LOG-MIB may be a misnomer. Further, though the
> MIB works closely with the SNMP-NOTIFICATIONS-MIB, it’s not part of the “core
> SNMP infrastructure”.
> So I’d prefer to leave the name as is.
> 
> 
> 
> The following are my responses to David’s comments:
> 
> > 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.
> 
> [*]
> I  reread the MIB after adding all the changes suggested by David, and feel
> comfortable with the new draft's use of RFC2119 words.
> 
> While we’re talking about using MAY/MUST etc., I wonder whether the following
> paragraph from Section 3.1.2 “Security” should be reworded
> a little stronger?:
> 
> When putting locally-generated Notifications into a named log, the
> managed system uses the security credentials associated with that log
> and applies the same access control rules as described for a
> Notification Originator in [RFC2573].
> 
> The wording I had in mind was:
> When putting locally-generated Notifications into a named log, the
> managed system MUST use the security credentials associated with that log
> and MUST apply the same access control rules as described for a
> Notification Originator in [RFC2573].
> 
> 
> > 2) please double check the 70-character limit. See =
> > nlmConfigLogFiltername and globalEntryLimit for examples.
> > 
> > 
> > 1. Abstract - "experimental" needs to be changed
> 
> [*] ok.
> 
> > 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".
> 
> [*] I agree with the “or to” change. I’d prefer “verify” instead of “determine”
> as a replacement
> text for “know”. I’ve changed the text to:
> Given the Notification Log MIB, individual MIBs bear less responsibility
> to record the transient information associated with an event against the
> possibility that the Notification message is lost, and applications can
> poll the log to verify that they have not missed important Notifications
> IF THEY suspect that they might have.
> 
> [*] Actually, I’d like to drop the “IF THEY suspect that they might have”, as
> it is an obvious
> implication. FYI,  “IF THEY” is in caps just to highlight the edit I made.
> 
> > 3.1.1. "combine information from multiple engines"=20
> >       I would add ",such as is in a mid-level manager," for clarity
> 
> [*] I’d prefer to leave the text as is - I think it is clear enough as it is.
> 
> > 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"
> 
> [*] I agree. I’ll change the text to:
> “A managed system with fewer resources may disallow the creation of
> named logs, providing only the default, null-named log.”
> 
> > 3.1.2. "the managed system does not apply access control ..." should =
> >       does be strengthed with an rfc2119 word?
> 
> [*] Agreed - I’d like to use “SHOULD NOT” for “does not”. Also, I’d like to
> make two further changes:
> 1. Rephrase the first sentence to be: “The managed system SHOULD NOT apply
> access control when adding remotely-generated Notifications into either a named
> log or the default, null-named log.”
> 
> 2.      I’d like to change “is left to” to “should be left to”.
> 
> Hence the old text below:
>         “When putting remotely-generated, the managed system does
>         not apply access control to the Notifications.  In those cases the
>         security of the information in the log is left to the normal, overall
>         access control for the log itself.”
> 
> will be changed to:  
> “The managed system SHOULD NOT apply access control when adding
> remotely-generated Notifications into either a named log or the default,
> null-named log. In those cases the security of the information in the log is
> left to the normal, overall access control for the log itself. ” 
> > 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.
> 
> [*] This is a question I’d like to redirect to Bob Stewart. I've sent him email
> about this.
> 
> > The MIB:
> > IMPORTS - "experimental" not needed
> > CONTACT-INFO ???
> > {experimental xx } -> { mib-2 xx } as per bert
> > import mib-2
> > get an IANA placement
> 
> [*] Ok. How do  I get an IANA placement? Does the MIB name issue need to be
> settled before I can get such a placement?
> 
> >       GlobalEntryLimit - why read-write? why not just agent controlled?
> 
> [*] I can think of a few reasons off the cuff:
> 1.      An application may find that the log is getting too big, and hence using
> up too much memory. An application may want to reset the notification log
> global size so othe, more important processes e.g. ospf, tcp, voip, security
> etc. can work without hiccups.
> 2.      A particular link may be quite reliable, e.g. if you have a
> point-to-point high-speed optical link - high speed, low collission, low noise.
> In such cases, notifications over such a link may not be lossy (except during
> optical-link failures). You would still want a minimal amount of logging due to
> the possibility of a link-failure and a lag before a backup mechanism can
> takeover.
> 3.      A quick-n-dirty way to shut off logging entirely, without losing any
> existing configuration - e.g. during debugging/performance testing, to judge
> the amount of resources that can “safely” be used by the Notification Log MIB
> during normal and/or critical network traffic  situations.
> 
> [*] I’d like to change the following text for this object to:
> “if an application changes the limit while there are Notifications
> in the log, the oldest Notifications ARE discarded to bring the log
> down to the new limit.”
> 
> to
> 
> 
> “if an application changes the limit while there are Notifications
> in the log, the oldest Notifications SHOULD BE discarded to bring the log
> down to the new limit.”
> 
> 
> >       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?
> 
> Ok. How about:
> “In the case where the Notification Log MIB is being monitored by multiple
> applications, reducing the value of nlmConfigGlobalEntryLimit by one
> application may cause Notifications to be discarded before the rest of the
> applications have had a chance to see them. Synchronization between multiple
> applications using the Notification Log MIB is beyond the scope of this MIB.”
> 
> > GlobalAgeOut - If an application changes the time .. older than the =
> > time... seems slightly incorrect. I think using "value is less =
> > ambiguous than "time".
> >
> 
> [*] Ok. How about:
> >“If an application changes the value of nlmConfigGlobalAgeOut, Notifications
> >older than the new
>  > time are discarded to meet the new time.”
> 
> [*] It is possible that multiple applications are polling this MIB, and hence
> we must again deal with the loss of Notifications (due to purging) before all
> applications have had a chance to read them. So  I propose adding the following
> wording:
> 
> >“In the case where the Notification Log MIB is being monitored by multiple
> >applications, reducing the value of nlmConfigGlobalAgeOut by one application
> >may cause Notifications to be discarded before the rest of the applications
> >have had a chance to see them. Synchronization between multiple >applications
> using the Notification Log MIB is beyond the scope of this MIB.”
> 
> [*] Im not sure how to address the denial of service issue. I'm not a security
> weenie,  but I’d assume that a secure SNMP implementation in the field would
> have an authpriv SNMPv3 user with a secure password, and access to other
> users/ommunity strings for this (ond other similar objects) must be denied. Of
> course, this doesn’t cover the case where the implementation does not support
> v1/v2c, in which case a malicious person could always set this object to either
> a really low value or an abysmally large value, thereby either disabling
> logging or permitting the log to consume too many resources. For v2c, however,
> access to such an object can be view-excluded for all communities?? And for v1,
> an implementation that’s incompatible with view-based access can simply
> implement it as read-only. 
> 
> > 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, =
> 
> [*] I don’t see why the sums of the individual log limits cannot be greater (or
> less than)  the globalLogLimit, so long as the total messages stored is less
> than or equal to the globalLimit..
> In the case where the sum of the individual log limits equals the global limit,
> the oldest notification shoul be dropped to accomodate the new one.
> 
> > could this be used to cause denial of service (or preferential =
> > treatment)?
> 
> [*] same argument as above.
> 
> > AdminStatus - please comment on NMS contention. (Recurring theme; Maybe =
> > this should be done in overview or security considerations).
> 
> [*] Since it’s a recurring theme, I’d say the section on "security" should
> handle this, as losing notifications due to an application’s changing config
> objects is a security issue.
> 
> > EntryStatus - wouldn't this be more obviously a RowStatus if named =
> Ø       nlmConfigLogRowStatus?
> 
> [*] I find it clear as is, but if there is consensus, we can change it.
> 
> >       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).
> >
> 
> [*] David, I don’t see how they can add the security credentials to the row -
> can you explain this to me? Also, if you come up with the wording (since I’m
> unclear about what you’re pointing out), I’ll add it in.
> 
> > 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.
> 
> [*] You have valid concerns about denial of service. But what mechanism (other
> than secure SNMPv3, or using IP Security to scramble packets, using views to
> exclude such objects from global configuration etc.) can be incorporated into
> the MIB for preventing denial of service? O do you want this to be described as
> a potential issue for applications to be aware of?
> 
> > 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"?
> 
> [*] I’d rather not make it a “RECOMMENDED” behavior - on systems where the
> management system can be restarted independent of the rest of the system, there
> may be a need to save some or all of the config, esp. authentication failure
> notifications, in order to debug what may have caused the restart of the
> management system.
> 
> >       - nlmLogTime for entries before the reset **MUST be** set to 0.
> 
> [*] I’d rather this wording be “SHOULD BE set to 0” - some implementations may
> have special ways to deal with such management system resets, and may want the
> nlmLogTime to be as is.
> 
> > 
> > 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.
> 
> [*] I believe this is clear as is. When an implementor implements the mandatory
> pieces of this MIB, he’ll be forced to consider this issue when he reads the
> LogEntry description.
> 
> > 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?
> 
> [*] Is there a preference to discard all the old entries? If so, we can say
> “it is recommended that the implementation discard all existing entries”.
> But I’d rather see a consensus on this on the disman list - I don’t have enough
> experience to judge whether this would be a good strategy or not.
> 
> > =09
> > EngineID - is there any way to preserve the address?
> 
> [*] I would not like to provide a means to preserve the address - if the
> managed system is using HSRP or VRRP (standby-routing protocols), or DHCP,
> storing the IP address may be misleading.
> 
> > NotificationID - what to do for v1 traps?
> >       identifer s/b identifier
> 
> [*] I have no idea what to do for such traps…Any suggestions?
> 
> > LogVariableEntries - should this be fate-sharing with LogTable? It =
> > isn't discussed. One would expect an rfc2119 word somewhere here.
> 
> [*] Don’t follow what the reviewer meant by the above comment.
> David, could you clarify?
> 
> > 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. ;-)
> 
> [*] How about changing “is instantiated” to “MUST BE instantiated”? 
> 
> > 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
> 
> [*] I’ve checked them, and could not find any (other than the ones you pointed
> out) that are non-compliant. Please let me know iof I missed any after I submit
> the updated draft.
> 
>         OBJECT nlmConfigLogEntryStatus
>             MIN-ACCESS read-only
>             DESCRIPTION
>                 "Implementations may not allow the creation of named logs."
> 
> I’ll change “may not allow” to “may disallow” in the above text.
> 
> 
> > 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."
> 
> [*] Ok. How about:
> “should not be implemented on systems that do not implement a wall clock date.”
> ???
> 
> > 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?
> 
> [*] I’ll wait for Bert’s input on this.
> 
> > Author's Address - I guess another one is needed here.
> 
> [*]
> Ok. Will change it to mine.
> 
> 
> Sharon Chisholm’s comments:
> 
> > 1. I would have to agree that SNMP-NOTIFICATION-LOG-MIB better
> > fits since the MIB will also be used in a non-distributed manner.
> 
> [*] I prefer leaving the name of the MIB as is for reasons stated earlier.
> 
> > 2. An unrelated question: Does nlmStatsLogNotificationsLogged minus
> > nlmStatsLogNotificationsBumped give me the current Log Index?
> > Is it too late to request one object to query to get this number?
> 
> [*] Why do you want a number reflecting such a computation? Or do you simply
> want an object reflecting the latest entry logged in the MIB? If such an object
> were provided, you’d get into security issues like
>         “what if the latest notification logged is not in your user/community
> string’s view?”
> 
> Ram
> 
> 
> 
> 
>

---

From: "Bert Wijnen" <[email-masked]>
Date: Mon, 18 Oct 99 20:58:05 DST

Ref:  Your note of Mon, 18 Oct 1999 10:42:06 -0700 (PDT)

Subject: Re:   Fwd: Responses to comments on the NOTIFICATIOn-LOG-MIB

Answering the questions you raised (I hope I got the ones I had to
address, if not, pls let me know)

> > 1. Root the mib under mib-2 xx, do import mib-2 and do not import
So if you know how to do this, then the mib-2 question below should be
easy too.

> [*] Didnt follow what was needed here Looked at the Expression and Event
> MIBs, but couldnt figure out what Bert had indicated.
>
We prefer MIBs to have a REVISION, even in the first release.
So you should have something similar as the 2nd REVISION clause
in the MIB in RFC2571. The REVISION DATE and the LAST-UPDATED date
should be the same.

> meant. Will ask him for clarifications on this.
The IESG has started to ask for an IPR statement as per RFC2026
section 10.4 sub A and B (possibly also C).
See for example section 10 in RFC2674.

> settled before I can get such a placement?
So here you do the same as above (under question 1).
You do a
   ::= { mib-2 xx }      -- Assigned by IANA

Then when the document comes to the RFC-Editor the IANA will
be called for an assignment.

Bert