Subject: Re: Current Log Index in Notification log MIB?

From: Randy Presuhn <[email-masked]>
Date: Mon, 13 Dec 1999 10:47:38 -0800 (PST)

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: [email-masked]
> Subject: Current Log Index in Notification log MIB?
> Date: Tue, 16 Nov 1999 15:16:36 -0500
> List-Id: IETF disman Working Group mailing list <[email-masked]>
...
> A while back I had suggested the addition of a current log index in the 
> notification log MIB, to allow the manager to efficiently tell if anything
> new
> has been added to the log.
> 
> There was one objection, and one person saying that it would not be too
> evil.  What is the current status of this suggestion?

I'm very reluctant to authorize changes this late in the process,
unless they are needed to fix a specific problem (rather than
add an additional feature).  As it is, the editor has quite a bit
of work just to handle the IESG reviewer's (very helpful) comments.

I suggest that this addition be left for consideration after
we've had some implementation and deployment experience.

> The MIB objects would look something like one of the two possibilities I
> have outlined below.  Are their still objections to this because of views?  

I don't think so.

> Is it too late to get it added?

New features during WG last call is rather too late, especially
when a document is as far behind schedule as this one.
However, we shouldn't lose track of this suggestion, and
should give it close consideration when it's time to consider
progression from Proposed to Draft (or cycling).

> nlmCurrentLogIndex OBJECT-TYPE
>     SYNTAX     Unsigned32 (0..4294967295)
>     MAX-ACCESS not-accessible
>     STATUS     current
>     DESCRIPTION
>         "The current largest value of the log index in 
> 	the table of logged notifications.  This object 
>  	is intended  to quickly let the management
> 	station know if there have been any new traps
> 	added to the notification log table.  It is meant
> 	to correspond to nlmLogIndex. "
>     ::= { nlmLog x }

The current "wrapping" behaviour means this object wouldn't
have the desired behaviour in implementations that didn't
delete everything upon index wrap.  Furthermore, when there
are multiple logs, this doesn't tell the manager which one.

> OR
> 
> nlmCurrentLogTable OBJECT-TYPE
>     SYNTAX      SEQUENCE OF NlmCurrentLogEntry
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>      "A table of current log indices for Notification log entries."
>     ::= { nlmLog x }
> 
> nlmCurrentLogEntry OBJECT-TYPE
>     SYNTAX      NlmCurrentLogEntry
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>      "Information about the current/latest Notification log entry."
>     INDEX       { nlmLogName}
>     ::= { nlmCurrentLogTable 1 }
> 
> NlmLogEntry ::= SEQUENCE {
>     nlmCurrentLogIndex               Unsigned32,
>  }
> 
> nlmCurrentLogIndex OBJECT-TYPE
>     SYNTAX     Unsigned32 (1..4294967295)
>     MAX-ACCESS not-accessible
>     STATUS     current
>     DESCRIPTION
>        "The current largest value of the log index in 
> 	the table of logged notifications.  This object 
>  	is intended to quickly let the management
> 	station know if there have been any new traps
> 	added to the notification log table.  It is meant
> 	to correspond to nlmLogIndex. "
>     ::= { nlmCurrentLogEntry 1 }
...

This one is better, though it still runs into trouble with the
wrap behaviour.

 -------------------------N-E-W---A-D-D-R-E-S-S--------------------------
 Randy Presuhn           [email-masked]       http://www.bmc.com/
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141  2141 N. First Street
 Fax:   +1 408 965-0359  San Jose, California 95131  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's should be coincidental.
 ------------------------------------------------------------------------

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 14 Dec 1999 06:33:43 -0600

hi

Ok, that makes sense.  I have had some discussions with Ram, the
current editor, and am now convinced that I can use
nlmStatsLogNotificationsLogged for some of what I require the 
current log Index for.

I still think a table of current log indices would be handy
to have someday. I think the current log index would wrap 
when the logIndex wraps.  I am not sure what you mean you 
mean by a wrapping problem.

thanks

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]]
Sent: Monday, December 13, 1999 1:48 PM
To: [email-masked]
Subject: Re: Current Log Index in Notification log MIB?

Hi -

...

I don't think so.

...

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 14 Dec 1999 09:56:23 -0800 (PST)

Hi 

> To: Randy Presuhn <[email-masked]>, [email-masked]
> Subject: RE: Current Log Index in Notification log MIB?
> Date: Tue, 14 Dec 1999 06:33:43 -0600
...
(I've deleted the bizarre HTML copy of the message that Sharon's
mailer seems to like to send.)
...
> when the logIndex wraps.  
...

That's not what your suggested replacement text says.  Specifically,
your proposal says:

|         "The current largest value of the log index in 
|       the table of logged notifications.  This object 

This would produce the desired result only if the log was
emptied before wrapping the index.  The current wording does
not require implementations to empty the log before wrapping
the index.  Thus, after wrap, the "current largest value of
the log index" could potentially refer to an old log entry.
To get the desired effect, one would have to replace the first
sentence with something like "This object reports the value of
the log index for the most recent entry in the corresponding
table of logged notifications."

>                           I am not sure what you mean you 
...

The current draft permits two different, implementation-specific
behaviours on wrap.  Which of these is implemented will affect
how a management application goes about finding "all log records
that have been added since I last checked".

I think an algorithm that would tolerate both would need to:
     -  remember the index from the last walk of the table
     -  if the index for the retrieved entry hits the max,
        start over at the top of the table
     -  check the nlmLogDateAndTime (if implemented) for each entry 
        to make sure it is greater than or equal to that from the last
        table walk
     -  terminate after nlmConfigLogEntryLimit iterations

The nlmLogTime column cannot be used as a termination condition
if the log is potentially persistant, thus the need for the last
termination condition.

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 15 Dec 1999 07:31:10 -0600

hi

> mailer seems to like to send.)
Sorry about that.  You're not the first to complain. I don't think
It's something I can turn off. :-(

> |       the table of logged notifications.  This object 
I think I meant to say "latest value of the log index" which
handles the wrapping from the MIB implementer's point of view.
It's what I mean now anyways.

> if the log is potentially persistant, thus the need for the last

Oh! I'm with you now.  A wrapping problem when consuming the table,
not while maintaining the index. Your algorithm seems reasonable. 
I can't think of anything short of adding a slew of objects we don't
want to maintain that could make it more efficient.

It is exactly these wrapping cases that that make the argument for
having a current log Index, instead of just a statistic of number of 
logged messages.

Sharon

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 15 Dec 1999 10:11:15 -0800 (PST)

Hi -

> Date: Wed, 15 Dec 1999 07:31:10 -0600
...
...

At this stage in the process, I hope you can understand
my reluctance to add more objects.  We have an apparently
reasonable algorithm that will do the right thing with the
existing objects.  The number of GetNext exchanges needed is
the same.  The additional object would be a win only to the
extent that it would permit a command generator application
to tune the max-repetitions of a GetBulk so as to not pick
up extraneous stuff.

So, unless there's a storm of protest from other interested
folk, as WG chair I suggest we leave it alone so we can get
this thing published.

---

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 15 Dec 1999 12:19:43 -0600

hi

That's fine.  I have already come to terms with the fact
it I won't see it in the initial version.  I'm just 
saying that if someone does another, we should put
the current log index in.

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]]
Sent: Wednesday, December 15, 1999 1:11 PM
To: [email-masked]
Subject: RE: Current Log Index in Notification log MIB?

Hi -

...
...