Subject: Notification Log MIB open issues

From: Ram Kavasseri <[email-masked]>
Date: Thu, 21 Oct 1999 17:11:15 -0700

Here's a list of open issues for the Notification Log MIB:

Nlm-01  Should this MIB be renamed? If so, should the name be Disman Notification Log MIB
or Snmp Notification Log MIB. Randy had proposed a consensus that it be Disman Notification Log MIB,
but there have been several folks who've requested Snmp Notification Log MIB.
And I'd like to leave the name as is...

Nlm-02 RMON2's TimeFilter provides similar functionality to that described in Section 3.2.3, 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.
 
Nlm-03 Since the description for nlmConfigLogEntryStatus says that the
system should record the credentials, shouldn't we put a warning here to protect those
credentials? 
 
Nlm-04 NotificationsBumped - we don't include the AgeOuts. A rogue NMS (or a rogue
operator) can 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. What, if anything, should
be done about this denial-of-service issue?

Nlm-05 In the DESCRIPTION for nlmLogIndex - 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?

Nlm-06 NotificationID - what to do for v1 traps?

Ram Kavasseri
-----
Cisco Systems, Inc.                      
170 West Tasman Drive  
San Jose, CA 95134-1706

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 22 Oct 1999 09:11:02 -0700 (PDT)

Hi -

> Date: Thu, 21 Oct 1999 17:11:15 -0700
> To: [email-masked]
> From: Ram Kavasseri <[email-masked]>
> Subject: Notification Log MIB open issues
...
> Here's a list of open issues for the Notification Log MIB:

If it takes technical change to fix this, I fear we'll need to run this
thing through yet another WG last call, and hold its companion documents
until it's ready.  Please prove me wrong.

...
> That suggestion can of course be considered after this review.

I disagree.  The semantics of the index defined here are quite different from
a TimeFilter.  We should not be messing with it at this late stage.

> system should record the credentials, shouldn't we put a warning here to protect those

Belongs in the Security Considerations section, which is effectively section
3 in this document, especially 3.1.2, second paragraph.

> be done about this denial-of-service issue?

Describe it in the security considerations section with standard boilerplate
about protecting read-write objects.

> Nlm-05 In the DESCRIPTION for nlmLogIndex - what exactly does "flush existing entries"

I believe it says that when the index wraps, an implementaion may discard
all the old entries, in order to preserve the index semantics.  I'd prefer
something a bit more deterministic.

> Can this be tightened up to improve interoperability? What should an NMS expect from a

As it's written, managers should expect unpredictable behaviour as the
index value becomes large.  Entries may disappear due to index wrapping.

> Nlm-06 NotificationID - what to do for v1 traps?

I'd refer to the SNMPv3 WG's coex document.

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