Subject: Re: re-review of Notify Log MIB

From: Randy Presuhn <[email-masked]>
Date: Thu, 16 Dec 1999 16:50:05 -0800 (PST)

Hi -

Just for the benefit of the WG, here's a snapshot of the
editor/reviewer/chair discussion of the Log MIB.  I'll
forward my comments on the not-completely-resolved bits
shortly.  (Note that M*L*M replaced something else in
order to get past the spam filters.)

 ------------------------------------------------------------------------
 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 [email-masked] Thu Dec 16 15:49:13 PST 1999
|Date: Thu, 16 Dec 1999 15:35:28 -0800
|To: Randy Presuhn <[email-masked]>, [email-masked]
|From: Ramanathan Kavasseri <[email-masked]>
|Subject: RE: re-review of Notify Log MIB
|Cc: [email-masked], [email-masked], [email-masked]
|
|Randy & David,
|
|my responses to your comments are marked by [*] below.
|
|At 01:27 PM 12/9/99 -0800, Randy Presuhn wrote:
|>Hi -
|>
|>> From: "Harrington, David" <[email-masked]>
|>> To: "'Ramanathan Kavasseri'" <[email-masked]>,
|>>         "D. Harrington"
|>> 	<[email-masked]>,
|>>         [email-masked], "Presuhn, Randy" <[email-masked]>
|>> Cc: [email-masked]
|>> Subject: RE: re-review of Notify Log MIB
|>> Date: Wed, 8 Dec 1999 11:57:58 -0500 
|>> 
|>> Hi Ram,
|>> 
|>> My job in reviewing the document is to ensure that it meets minimum
|>> requirements for standards-track RFCs, to be comfortable that the
|>> specification is clear and unambiguous to implementors of agents and
|>> managers and to deployers, and to be comfortable that there are no obvious
|>> design flaws.
|
|[*]
|I understand, and am glad you, Randy and Bert have been really
|patient and helpful while I learn the rfc-editing process...
|
|>> There are a few outstanding issues, and some that need a ruling from the
|>> chair.
|>
|>I responded to these before, but I guess someone didn't get my response.
|>ok, here goes again.
|>
|>> > >Most documents I have read/reviewed capitalize 
|>> > MUST/SHOULD/MAY to make
|>> > >it clear that they are used in the RFC2119 sense. Some readers think
|>> > >that non-capitalized must/should/may are not binding. This document
|>> > >might benefit from following the capitalization convention.
|>> > 
|>> > The following standard text in the Abstract is clear about how these
|>> > keywords need to be interpreted:
|>> > 	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
|>> > "SHALL NOT",
|>> > 	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
|>> > "OPTIONAL" in this
|>> > 	document are to be interpreted as described in RFC 2119.
|>> > 
|>> > With the above text, I feel there's no need to capitalize 
|>> > every occurrence
|>> > of the
|>> > above keywords - but if there's consensus, I'll make the 
|>> > changes in this
|>> > as well as expression and event mibs.
|>> > 
|>> 
|>> This seems like a very small and easy change to eliminate possible
|>> ambiguity. 
|>> 
|>> I defer to the chair.
|>
|>Though I personally think the capitalization is overkill, that's not
|>been the way it's traditionally been handled here in the IETF.  Where
|>those words are used in the RFC 2119 sense, they should be capitalized.
|
|[*] Ok.
|
|>> > >Section 3.1.1 "combine information from multiple engines" could be
|>> > >misleading. There have been instances where people have mistakenly
|>> > >thought that one MIB could support multiple engineIDs.	That is
|>> > >absolutely NOT the recommended design from the SNMPv3 
|>> > working group. I
|>> > >consider it	important to make it clear to readers that this
|>> > >engine-aggregation is for entities such as mid-level 
|>> > managers, not for
|>> > >typical agents.
|>> > 
|>> > I feel it is sufficiently evident that any agent that is storing
|>> > notifications in its notification-log-mib from other agents is already
|>> > acting as a Mid-Level-Manager...I'm not convinced extra wording is
|>> > necessary...Perhaps you can explain to me with an example how 
|>> > this could be
|>> > misinterpreted?
|>> 
|>> draft-aboba-acct-02.txt, a document of the AAA WG, describes how, for a
|>> device
|>> that is used by multiple domains and which must constrain what data can be
|>> seen
|>> by applications of a particular domain to the data that applies to that
|>> domain,
|>> an agent should be written with multiple engineIDs, one engineID for each
|>> domain. This scheme would have managers sending different engineIDs in their
|>> requests to specify from which domain the request comes. This is obviously
|>> not consistent with the SNMP design, for those of us who really understand
|>> SNMP, but it is apprarently NOT obvious to seasoned IETF-ers who do not
|>> really understand SNMP. The AAA document will be corrected, but it shows
|>> that there is confusion about the purpose of the engineID and its uses.
|>> 
|>> When I read the text in the notify log mib which talks about multiple
|>> engineIDs,
|>> which occurs before any discussion of why one would put the data from
|>> multiple 
|>> engines into the log(s), it sounded to me like the document was suggesting
|>> that for a system with multiple engines, the logs could be stored in one
|>> common 
|>> notify-log MIB, which is similar to what the AAA document suggests. If I am
|>> uncertain about the recommended use proposed by this text, then somebody
|>> that does not know SNMP as well as I do can certainly also find it to be
|>> unclear.
|>
|>The current document does permit (but does not require) a log on a system
|>to record notifications that came to it by way of different SNMP engines.
|>
|>> Note that your interpretation is that an **agent** "is storing notifications
|>> in its notification-log-mib from other" **agents**, but the text talks about
|>> combining information from multiple **engines**, not multiple **agents**.
|>> Not everyone will interpret "combine information from multiple engines" the
|>> way you did. 
|>
|>Indeed, this is a very important distinction.
|>
|>> Therefore I request that it be made more explicit to improve its clarity, to
|>> prevent ambiguity, and to help vendors developer interoperable
|>> implementations.
|>
|>Agreed.  There are two distinct information flows that one MIGHT log.
|>The first is the stuff that is actually observed in protocol as
|>informs and traps.  In this case, "notification" is a shorthand
|>for "informs and traps".  The second flow comprises the notifications
|>delivered to an engine at the interface to a notification originator.
|
|[*]
|I followed the entire argument, until I ran into the last sentence
|above describing the second flow...Do you mean the second flow
|is some sort of internal API function call/rpc between two engines
|(or an engine and a non-SNMP device) on the same system?
|
|>The first paragraph of clause 3 is talking about the second flow;
|>much of the rest of the document seems to be talking about the
|>first flow.
|>
|>In the first case, there is both an SNMP engine ID and a ContextEngineId
|>to record.  Section 3.1.1 (and the MIB) don't deal with this properly.
|>Suggestion: delete the second and third paragraphs of 3.1.1; delete the
|>last sentence of 3.1.1, updating conformance statements accordingly; add
|>an object to hold the ContextEngineId.  add text to 3.1.1 to clarify
|>that the "multiple SNMP engine" case only happens when it's the first
|>flow that's being monitored.
|>
|>The resulting MIB should be able to handle both cases; it would probably
|>be helpful to describe the two "taps", though we go the path of arguing
|>that the second one should be modeled as the SNMP engine sending the
|>notification to itself.
|
|[*] If I followed correctly, the "second flow" is an internal API call,
|and shouldn't be discussed at all...I'm puzzled here - could you rephrase
|it in simpler terms (perhaps with an example) to help me follow? Thanks.
|
|>> > 
|>> > >Section 3.1.2 - "Synchronization ... beyond the scope of this MIB."
|>> > > The concerns I 
|>> > > raised were for
|>> > >nlmConfigGlobalEntryLimit, nlmConfigLogEntryLimit,
|>> > >nlmConfigLogAdminStatus, and nlmStatsLogNotificationsBumped. 
|>> > PLease add
|>> > >some comments about the issues regarding these objects in 
|>> > multi-manager
|>> > >systems.
|>> > 
|>> I feel that "Synchronization ... beyond the scope of this MIB." falls into
|>> the same category as a Security Considerations section that just says
|>> "Security is not discussed in this document." It's a blow-off - pure and
|>> simple. 
|>
|>yup.
|>
|>> [soap]
|>> Put yourself in the shoes of a manager developer or a network operator that
|>> could be impacted by these issues, and see whether you think your one small
|>> section of text buried amongst a bunch of other text is adequate warning
|>> about the potential repercussions, and whether your small section of text
|>> provides adequate warning to network security administrators to ensure that
|>> they configure access control appropriately to avoid the negative
|>> consequences of contention between multiple managers to set these very
|>> specific objects. Then tell me if I, as a vendor of management applications,
|>> should be satisfied with your blow-off of this issue. 
|>> 
|>> I'm not asking you to solve the problem; I'm asking to have adequate
|>> warnings inserted as relevant places in the text.
|
|[*] Ok. Looks like I misunderstood you - I though you'd
|wanted the MIB to address how the problem should be solved...
|I agree that adding adequate warnings to the configuration objects 
|(as you suggest below) is a good thing, and will do that.
|:-)
|
|>> [soap off]
|>
|>agreed.
|>
|>> Now let's see if we can just solve the problem satisfactorily.
|
|[*] Ok, I get a little confused/worried when I see "solve the problem",
|but I think you mean the "problem of not having adequate warnings"...
|
|>> Many people use the MIB without all the surrounding text, so a developer
|>> told to  implement these objects, or a network administrator reading the MIB
|>> to see what security/control issues might apply, may not even see your text.
|>> 
|>> Please add a warning to each of the objects named,
|>> "Please be aware that contention between multiple managers trying to set
|>> this object to different values may affect the reliability and completeness
|>> of the data seen by each manager."
|>> This text should work for each of the read-write values, and I'll accept the
|>> Bumps object as is.  
|>> Would that be acceptable to you?
|>
|>It's fine with me.
|
|[*] Ok. Will do.
|
|>> > 
|>> > I suppose this means we'll
|>> > need to include text specifying which value (ageOut or 
|>> > globalEntryLimit)
|>> > "SHOULD" take precedence over the other...Comments?
|>> 
|>> I would assume <limit> always takes precedence over <ageout>.
|>> If the preferred answer is not clear, it should be raised to the chair,
|>> and if he doesn't have a definite feel for the consensus, it can go to the
|>> WG.
|>
|>The current language is too loose.  "SHOULD" is too lose.
|>Log size limits take precedence over age.  Period.
|
|[*] Ok.
|
|>> > 
|>> > >nlmLogIndex. 
|>> > >	Why must this be monotonically increasing - isn't that an
|>> > >implementation choice?	If an agent MAY choose to NOT 
|>> > flush, then
|>> > >ordering is irrelevant - If ordering is irrelevant, why must it be
|>> > >monotonically increasing? "may flush" can lead to interoperabiolity
|>> > >issues. Is this MAY? "flush" is ambiguous. Should this be delete? If
|>> > >flushing occurs, MUST ALL entries be deleted? if partial 
|>> > deletion, MUST
|>> > >deleted entries be contiguous? Can a sparse matrix result? 
|>> > If so, can an
|>> > >agent "fill in the gaps"? or must an agent reuse lower-valued indexes
|>> > >even if higher-valued indexes are unused?
|>> > 
|>> > I agree with you that if an agent MAY choose to NOT flush, 
|>> > then ordering is
|>> > irrelevant. Here's why I think ordering is relevant, and MUST be
|>> > monotonically increasing:
|>> 
|>> The document as written does not clearly indicate the precedence of ordering
|>> and optional "flushing"; it is ambiguous on this point. If consensus on the
|>> issue is not clear, it should probably go back to the WG for further
|>> consideration.
|>
|>I'd like the handling of wrap behaviour to be deterministic, too.
|>Let's make the flush mandatory.
|>If this proves to be operationally problematic, we can fix it
|>and cycle at proposed.
|>
|
|[*] Ok. will make the "flush mandatory".
|
|>> > Managers will probably use the notificationLogMIB to increase 
|>> > the chance of
|>> > not losing traps. An efficient way to monitor for lost 
|>> > notifications is to:
|>> > 1. Poll the nlmStatsLogNotificationsLogged periodically to 
|>> > see how many
|>> > traps were sent.
|>> > 2. Keep a count of how many traps you received. When your count is
|>> > out-of-sync with nlmStatsLogNotificationsLogged, this is an 
|>> > indication that you
|>> > may have lost a notification. 
|>> 
|>> 
|>> nlmStatsLogNotificationsLogged doesn't count how many traps were SENT, it
|>> counts how many were LOGGED, and is incremented multiple times if a
|>> notification SENT once is LOGGED multiple times. If I set up two logs and
|>> logged every trap to both logs, I would be constantly tryong to synchronize
|>> my logs, much to the detriment of the MIB-owner devie and network bandwidth.
|>
|
|[*] Ok, good point - didn't see that coming. :-)
|
|>yup.  I don't think the detection of notification loss was a design
|>requirement.  Something like a CMIP disseminator (a weird hybrid of
|>an event forwarding discriminator and a log) would be needed to do
|>this.
|>
|
|[*] Ok, gotta wear my greenhorn hat again - "CMIP disseminator"?
|"Event forwarding discriminator?" Can you point me to a book
|(or educate me) so I know what these devices are?
|
|>> 
|>> > 3. Poll the agent to find out which notification (if any) 
|>> > you've lost. If
|>> > the log index
|>> > were not monotonically, the manager will need to read in the 
|>> > entire log. If it
|>> > were monotonically increasing, then all he needs to do is do 
|>> > a get-next from
|>> > the last index that he polled for.
|>> > 
|>> > Goiung back to the point you raised about "wrapping of the 
|>> > logIndex back to 1",
|>> > if we don't delete all the notification logs in the table, 
|>> > then we'll be
|>> > unable to determine
|>> > which notification we lost without polling the ENTIRE table. Ouch!
|>> > For that alone, I'd say an implementation MUST delete all 
|>> > notifications in
|>> > the log at that time.
|>> > Comments?
|>> > 
|>> 
|>> 
|>> If you have index-wrap, then the assumption that all newer entries will have
|>> higher indexes doesn't hold up. A manager's algorithm must then handle "may
|>> flush" scenarios, possibly including fill-in-the-gaps numbering, etc. The
|>> document is not sufficiently clear to prevent potential interoperability
|>> problems caused by unwarranted assumptions.
|>> 
|>> It is up to the WG to reach a consensus on this issue; consensus is not
|>> apparent in the current descriptions.
|>
|>I think the proper solution would be to use nlmLogDateAndTime as the
|>first index.  However, there was vocal WG opposition to this.  The
|>reasonable fall-back I'd recommend is to make the flush on wrap
|>mandatory.  Clause 3.2.3 needs to be fixed appropriately.
|
|[*] I will fix 3.2.3.
|
|>> > >nlmLogTable says nlmLogTime "should be set to 0." on reset. 
|>> > Should this
|>> > >be a MUST? 
|>> > 
|>> > It should be a MUST. Is it possible to store the snmpBoots 
|>> > value (or some other
|>> > form of discontinuity object) when the
|>> > notification was logged? That way, it can be a 
|>> > "discontinuity" object, and save
|>> > work for the management station in terms of going through the 
|>> > entire log
|>> > and resetting the time for each log to zero? I guess the flip side
|>> > to the argument is the e xtra memory taken for each such 
|>> > discontinuity object.
|>> > 
|>> 
|>> It was not clear to me that it was the management station's responsibility
|>> to reset the time for each log to zero. I assumed it was the responsibility
|>> of the MIB-owner (the agent or mid-level-manager). This point needs to be
|>> clarified.
|
|[*]
|A couple of points - I really need to kick myself for saying "management
|station". I meant "agent or mid-level manager". I was hoping the
|"owner of the MIB (agent or M*L*M)" could simply set one discontinuity
|object, so as to save the CPU cost of having to
|cycle through every log and set the time to zero.
|Comments on this?
|
|>Uh, this wouldn't fly; the objects are read-only.  The log implementation
|>would have to do it.
|>
|>> > 
|>> > >nlmLogEngineID
|>> > >	Withuot this information, or the SNMPv1 address, an NMS cannot
|>> > >determine which system originated the notification. Can the 
|>> > address of
|>> > >an SNMPv1 agwent be preserved somehow? Without this info, the trap is
|>> > >virtually useless. 
|>> > >	If I receive an SNMPv1 trap, and I know the engineID 
|>> > that has been
|>> > >assigned to that multilingual agent, may I instantiate this 
|>> > object with
|>> > >that engineID?
|>> > >	"An SNMPv1 system" is ambiguous. Is that a system that 
|>> > speaks SNMPv1,
|>> > >or speaks only SNMPv1? 
|>> > 
|>> This ambiguity needs to be resolved.
|>
|>Agreed.  The protocol is NOT a property of the system from
|>which the notification is received.  It is an attribute of
|>the notification.  We should not be talking about SNMPv1
|>systems.  We should talk about messages in SNMPv1 format.
|>
|>> > I would like to add another object - nlmLogEngineAddress - to 
|>> > store the ip
|>> > address of the originating SNMPv1 agent. Note that this is 
|>> > not fool-proof,
|>> > in that using NAT or a hot-standby
|>> > routing protocol will result in incorrect addresses (though 
|>> > why you'd want
|>> > a manager on the wrong side of a NAT beats me). The object 
|>> > should contain
|>> > the disclaimer that this
|>> > is not fool-proof, and also why it isn't fool-proof.
|>> > 
|>> agreed.
|>
|>ok.
|
|[*] Ok. Adding in Randy's comment that we should be talking about
|notifications (traps) in v1 message format, the ip address logged
|by nlmLogEngineAddress MUST be the source address of the packet
|that was received. I'm making this distinction because it is possible
|for an M*L*M to "aggregate" the ipaddresses of an engine (agent),
|and use one of the ipaddresses consistently to identify that engine,
|irrespective of the source address in the packet.
|Comments?
|
|>> > If the notification is from a multi-lingual agent, I'm 
|>> > hesitant to map the
|>> > ipaddress to its
|>> > engineID, though I can't figure out why this would be bad. 
|>> 
|>> I agree. and trust me, somebody would somehow figure a way to make it bad
|>> ;-)
|>> I suggest that both should never be filled in. If it was  a v1 trap, fill in
|>> the address; if v2, fill in the engineID. I don't know if there is a way to
|>> have one object that holds the appropriate choice, and still keep it clear
|>> and unambiguous for implementors and operators. 
|>
|>There should be distinct objects.
|>The address should always be filled in.
|>The engineId should be filled in if available, zero-length otherwise.
|>I think if we consider proxy situations, then we need a context engine id
|>as well as a context, too.
|
|[*] Ok, I'm weak in my knowledge of proxy situations and the use of the
|context engine id. My understanding is that in most cases, the
|engineId and contextEngineID will be the same, except if one engine
|is proxying for another engine, in which case the engineID is for
|the proxy engine, and the contextEngineID is for the notif originator.
|Is this correct?
|
|To summarize the comments above:
|1. store the ipaddress always (what about SNMP agents running over ipx?).
|2. store the engineID if v2/v3, 0 otherwise.
|3. store a contextEngineID if v3, 0 otherwise.
|4. store the context name always - default context is "".
|
|Does that sound ok?
|
|>> > 
|>> > >nlmLogVariables - what if actual count doesn't match this value?
|>> > 
|>> > Don't follow? isn't the nlmLogVariables computed when loggin 
|>> > the notification?
|>> > Then how could the count be wrong?
|>> 
|>> Have you experienced the same SNMP world I have? believe me, some
|>> implementation will get it wrong. I just don't want infinite loops or core
|>> dumps or unpredictable behavior because some application implementor assumed
|>> they could never be out of sync, but the agent implementor allowed it be out
|>> of sync for whatever reason. We don't want to try to anticipate what bugs
|>> could result from each design decision, but this design has a fairly obvious
|>> potential bug. I would like to see an implementation hint, for
|>> consistency in interpretation, that warns implementors that this object MUST
|>> be correct, or else one to application developers that they should not rely
|>> on this object.
|>> 
|>> I am willing to let this slide, but I don't feel comfortable with the design
|>> as is.
|>
|>It's redundant information, and, as such, a potential source of error.
|>I'd recommend eliminating this object.
|
|[*]
|I agree to eliminating this object.
|
|>> > 
|>> > >notificationLogLogGroup - if I implement a system that supports only
|>> > >locally-generated SMIv1 notifications, must I implement
|>> > >nlmLogVariableCounter64Val?
|>> > 
|>> > Hmmm, I dunno the best answer for this. I'd like to say "yes, 
|>> > and the value
|>> > should be zero always", but why implement an object if it will be
|>> > permanently zero.
|>> > I'm leaning towards a new complaince tatement for 
|>> > nlmLogVariableCounter64Val.
|>
|>We've played these silly games with Couter64 long enough.
|>For this MIB, it should be mandatory, even if some implementations
|>may never instantiate the variable.
|
|[*] Ok.
|
|>> > >notificationLogLogGroup - if I implement a system that supports only
|>> > >locally-generated SMIv2 notifications, must I implement
|>> > >nlmLogVariableOpaqueVal?
|>> > 
|>> > Same as above.
|>> > 
|>
|>I'd says there's even less of a question here.  Opaque may be used
|>in both SMIs and in all three protocols.  It needs to be mandatory.
|
|[*] Ok.
|
|>> WG chair - what is the consensus? or does this need to be discussed by the
|>> WG?
|>
|>Are things clearer now?
|
|[*] I think the MIB looks much clearer. But I have a question about where
|the MIB is in in its draft-life-cycle. Since we're adding a few objects
|and removing a few, do we go back to last-call? Do we
|post this to the disman wg and ask implementors to comment?
|Could you clue me in as to what I need to do after I send the updated
|draft to you (i.e. Randy+David+Bert)?
|
|Thanks,
|
|Ram
|
|>> 
|>> ------------------------- 
|>> David Harrington
|>> Spectrum Smart Networking
|>> Cabletron Systems Inc. 
|>> Phone: +1 603 337 7357
|>> Fax: +1 603 337 7370
|>> Email: [email-masked] 
|>> 
|>
|> -------------------------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: Randy Presuhn <[email-masked]>
Date: Thu, 16 Dec 1999 16:52:40 -0800 (PST)

Hi -

...

I'm trimming it down to just those items that weren't simply
"ok" resolutions.

...

Here's the current second paragraph of clause 3:
% 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.

There's a couple of ways that one could meet this requirement.
One would be to model the notifications going through the normal RFC
2573 SNMP-NOTIFICATION-MIB and SNMP-TARGET-MIB mechanisms, with one of
the destinations being the system where the log resides, which would
just happen to be the same systems that the TRAP/INFORM originated from.
Though in some regards baroque, this collapses all the access control
issues and allows local stuff and remote stuff to all be handled in
exactly the same way.  HOWEVER, THIS IS NOT WHAT WE DID.

The other way to meet this requirement is effectively allow the
log application to wire-tap into the notification-originators'
messages to the snmp engine.  This results in the access control
asymetries I raised as potential issues on the WG mailing list
last March.  With no one in the WG interested in addressing it,
we've left it alone.

We're not saying anything about how one would implement it, but
conceptually it might be simplest to think of as putting the tap
on the engine side of the sendPdu ASI.  I never said I liked
this approach!

The requirements in clause 3 make it clear that one of the motivations
for this thing is to help cope with non-reliable delivery of TRAPs
and (to a lesser extent) INFORMs.  The way the document is currently
formulated, this means recording potentially outgoing notifications.
(Whether this takes place before or after the processing in the
SNMP-NOTIFICATION-MIB might be an interesting discussion or an
implementation-specific matter.)  This is not what I would have
preferred, but it's what the WG agreed to.  Unless it is broken,
we shouldn't be trying to fix it now.

...

These are based on something called a CMISFilter (defined
in IS 9596) which provides a way of formulating simple (or
complex) expressions about that protocol's equivalent of a
variable binding list.  The CMISFilter is used in an EFD object
(event forwarding discriminator, defined in IS 10164-5, Event
Report Management Function, also known as X.734) to decide
what notifications should be put on the wire and sent to
various destinations, rather like the SNMP-NOTIFICATION-MIB
and SNMP-TARGET-MIB working together.

In IS 10164-6 (AKA X.735), the EFD is used to define a
log object, rather like what we're trying to do here.  The
disseminator is a really cool synthesis of the two concepts.
Think of it as a log.  The placement of log records into the
log is controlled by the filter expressions.  Log records are
removed from the log upon confirmation of delivery to their
ultimate recipients.

...

This still won't fly.  The objects are read-only.  The log implementation
has to do it.  The owner can't.  This is one of the bummer consequences
of RFC 2679's clarification of TimeStamp, and why I avoid them whenever
I can.  I'd be happier if the DateAndTime were mandatory and we got
rid of the TimeStamp, but that's NOT the WG consensus.

That's a higher-level application's job.  We should not be adding
such a requirement to the specification at this stage in the
process.

...

I think so.  Let's hope one of the proxy experts is following this.

If v1, I think (4) would be the community.

|Does that sound ok?

I think so.

...
...

WG last call has closed.  I've posted your message (and this
one) to the WG mailing list so that the folks who have put so
much effort into this don't feel left out or in the dark.

If anyone finds the cleanup / repairs problematic, they'll have
an opportunity to raise their objections during IETF last call.
Of course, I'd appreciate hearing those objections sooner
(on this list) so we can work things out.

I believe we have held to the spirit of the WG consensus,
even in cases that I personally disagree with.  We need to
finish these three documents.  Let's get the draft spun,
let our reviewer make sure we've handled his (extremely
valuable!) comments, and handed off to the IESG.

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 20 Dec 1999 10:52:14 -0500

hi

I'm not sure who is saying what in this discussion, but I
left to original headers in just in case someone else can
follow them.

I've tried to get rid of the extra garbage in my mail messages
with the help of some nice disman lurkers, but I have not had
any luck yet.  Sorry.

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]]
Sent: Thursday, December 16, 1999 7:50 PM
To: [email-masked]
Subject: Re: re-review of Notify Log MIB
<clip>
|<clip>
|>> The document as written does not clearly indicate the precedence of
ordering
|>> and optional "flushing"; it is ambiguous on this point. If consensus on
the
What!?  What is someone is consuming the log and has not finished consuming
the
entries you are flushing?  Doesn't it make more sense and keep things simple
and
keep the monotonically increasing index and discourage flushing? What good
is
the log if I don't have *any* guarantee that notifications logged within the
last few minutes are stored?

|
|>> > Managers will probably use the notificationLogMIB to increase 
|>> > the chance of
|>> > not losing traps. An efficient way to monitor for lost 
|>> > notifications is to:
|>> > 1. Poll the nlmStatsLogNotificationsLogged periodically to 
|>> > see how many
|>> > traps were sent.
|>> > 2. Keep a count of how many traps you received. When your count is
|>> > out-of-sync with nlmStatsLogNotificationsLogged, this is an 
|>> > indication that you
|>> > may have lost a notification. 
|>> 
|>> 
|>> nlmStatsLogNotificationsLogged doesn't count how many traps were SENT,
it
|>> counts how many were LOGGED, and is incremented multiple times if a
|>> notification SENT once is LOGGED multiple times. If I set up two logs
and
|>> logged every trap to both logs, I would be constantly tryong to
synchronize
|>> my logs, much to the detriment of the MIB-owner devie and network
bandwidth.
|>
|
|[*] Ok, good point - didn't see that coming. :-)
Actually, nlmStatsLogNotificationsLogged is part of the nlmStatsLogTable 
which is indexed by nlmLogName.  So, if you added it a notification to
more than one log, you would increment nlmStatsLogNotificationsLogged for
each of the logs, not one statistic more than once.  I think you guys were
thinking of nlmStatsGlobalNotificationsLogged.
nlmStatsLogNotificationsLogged 
can more or less be used when consuming the logs.

|
|>yup.  I don't think the detection of notification loss was a design
|>requirement. 
Perhaps not, but it is still an important use of the MIB in my 
somewhat biased opinion. 

|>> 
|>> > 3. Poll the agent to find out which notification (if any) 
|>> > you've lost. If
|>> > the log index
|>> > were not monotonically, the manager will need to read in the 
|>> > entire log. If it
|>> > were monotonically increasing, then all he needs to do is do 
|>> > a get-next from
|>> > the last index that he polled for.
|>> > 
|>> > Goiung back to the point you raised about "wrapping of the 
|>> > logIndex back to 1",
|>> > if we don't delete all the notification logs in the table, 
|>> > then we'll be
|>> > unable to determine
|>> > which notification we lost without polling the ENTIRE table. Ouch!
|>> > For that alone, I'd say an implementation MUST delete all 
|>> > notifications in
|>> > the log at that time.
|>> > Comments?
No, I thought randy posted a nice algorithm of how to deal with wrapping
while consuming the log.  Basically, if the next row in the table does not
exist you check back at the beginning of the table and check the nlmLogTime
or nlmLogDateAndTime.

|>> > 
|>> 
|>> 
|>> If you have index-wrap, then the assumption that all newer entries will
have
|>> higher indexes doesn't hold up. A manager's algorithm must then handle
"may
|>> flush" scenarios, possibly including fill-in-the-gaps numbering, etc.
The
|>> document is not sufficiently clear to prevent potential interoperability
|>> problems caused by unwarranted assumptions.
I would agree we want to make the document clear about wrapping and
flushing.
If we are going to allow some to wrap and some to flush, then it would be
nice to have a way for the consumer to tell which is being used.  But, I
must reiterate I don't really want to see unconsumed log entries being
flushed.

thanks

Sharon Chisholm
Preside Integrated Management
Nortel Networks
Ottawa, Ontario

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Mon, 20 Dec 1999 15:01:15 -0800

> exist you check back at the beginning of the table and check the nlmLogTime 

Ok. I didn't see that algorithm - it'll work for systems that support
nlmLogdateAndTime...What about those that do not have date
and time capability? 

Given the above algorithm, I'll be ok with dropping the "may flush
existing entries" text, but we should revisit this after implementation
experience...For systems that do not have date and time capability,
should nlmLogTime's DESCRIPTION be changed so that all
entries prior to the wrap have their nlmLogTime set to zero after the wrap?

Ram, with my head spinning...

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 20 Dec 1999 17:57:11 -0800 (PST)

Hi -

> Date: Mon, 20 Dec 1999 16:50:28 -0800
> To: Randy Presuhn <[email-masked]>, [email-masked]
> From: Ramanathan Kavasseri <[email-masked]>
> Subject: RE: re-review of Notify Log MIB
> List-Id: IETF disman Working Group mailing list <[email-masked]>
> 
> 
> 
> I've snipped out the parts that I addressed in my prev mail - there's only one issue that needed addressing below...
> 
> At 03:48 PM 12/20/99 -0800, Randy Presuhn wrote:
> >This is already required by RFC 2579 near the top of page 18.
> >Yet another reason why I really hate TimeStamp objects. :-)
> >I guess a reminder wouldn't hurt; I leave this to the editor's
> >discretion.
> 
> I'm still alittle in the dark. As I interpret it,
> RFC2579 says that TimeStamp objects shouldn't be changed (reset to zero)
> unless syspTime is reset due to a management (sub)system reset.

Correct.  I mis-interpreted your earlier message.
Log index wrap should have NO effect on TimeStamp values.

> Thus resetting the TimeStamps to zero is not an option. However, if I
> followed correctly, the text in RFC2579 page 18 says clearly that there
> can be ambiguities in the value of the TimeStamp objects due to a
> sysUpTime wrap, which is what (I think) you said could be added?

The RFC 2579 text is a red herring, my mistake.  I mis-interpreted your
earlier question.

> Note: I want to clarify that I followed what you meant, before I think about
> adding any text...
...

Thanks.  It looks like no text is needed.

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 20 Dec 1999 18:11:09 -0800 (PST)

Hi -

> Date: Mon, 20 Dec 1999 16:31:06 -0800
...
(much violent agreement deleted.  :-)
...
> >Sharon has argued that the "no flush on wrap" solution makes
> >more operational sense.  The only cases where it would be a
> >problem is systems that don't support DateAndTime that have
> >persistant log storage (pretty improbable) and stay up enough
> >to have logged more than 2^32-1 notifications.  Even then,
> >a heuristic could use the existance of a (probably huge) gap
> >in the indexes in addition to the TimeStamp to determine when
> >a walk has gone from new stuff into old stuff.
> 
> "heuristic" is a good term to use for this, since I can see corner
> cases like sysUpTime resetting after an index wrap that need
> to be accounted for.

Even if there were a sysUpTime reset (and even if log data
persists) a get-next or get-bulk retrieval of the data will
reveal a huge (on the order of 2^31 or larger) gap in the
index values corresponding to entries that have been aged
out or bumped.  An implementation that has the resources to
hold more entries than that is overwhelmingly likely to be
able to do DateAndTime.  The cases where this would fail
are pretty pathological: notifications arriving at a high
rate; a high-capacity log device, no DateAndTime support,
and (SysUpTime wraps) or (system resets and persistant log
entries).  Yes, it's a heuristic, but I think it's sufficient.

After we've had some implementation and deployment experience,
I think we should consider whether the TimeStamp helped us in
any configurations.

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 21 Dec 1999 07:01:49 -0600

hi

> But there is still no guarantee that the number a notification
> receiver application should have received will match the number
> that should have gone into a particular log.  Referring to
> the same snmpNotifyFilterTable entry does not imply that the
> log and the target would have the same credentials.
No, perhaps not.  I'll have to give that one some thought.

> Since there is a strong objection to "must flush", would there
> be any objections to resolving the IESG reviewer comment by
> deleting the words "and may flush existing entries" from the
> DESCRIPTION of nlmLogIndex?
You guys have more or less agreed to this later in the discussion, but
I agree that it should work as well.

Flushing on reboot is not really a problem, and is probably  expected
behaviour.  It would be nice to have the last couple notifications before
the system was rebooted, but since the reboot probably fixed whatever the
problem was, it becomes more of a "nice to have".  If the problem is 
persistent, than another notification will be generated which will then
be logged.

thanks

Sharon Chisholm