Subject: Re: review of draft-ietf-disman-notif-log-mib-04.txt

From: Bob Stewart <[email-masked]>
Date: Thu, 05 Nov 1998 12:43:30 -0500

At 12:31 PM 10/19/98 +0200, Juergen Schoenwaelder wrote:
> 1) The first sentence in section 3 defines what is meant by the term
>    Notification by saying that these are either Traps of Informs. I
>    think we need to be more explicit here that we talk about RFC 1905
>    Traps in order to avoid confusion with RFC 1157 Traps. We probably
>    want to add a reference to a document which describes how RFC 1157
>    Traps can be converted to RFC 1905 Traps in order to make this MIB
>    usable in SNMPv1 environments.

OK.

> 2) Section 3.1.1 refers to the "SNMPv3 architecture". The architecture
>    is version independent and we should therefore refer to the "SNMP
>    architecture".

OK.

> 3) Section 3.1.2 introduces the concept of named logs and how the
>    names can be used with VACM. In the Script and Scheduling MIBs, we
>    made the grouping of entries for access control explicit rather
>    than relying on a hierarchical naming system and VACM wild-carding
>    rules. I strongly suggest to be consistent in our MIBs and to
>    split the name into two parts, like in the Script and Scheduling
>    MIBs. The cost of doing this is one extra sub-identifier in the
>    OID. (We can remove the nlmConfig, nlmStats and nlmLog nodes to
>    compensate for that if people think this is too expensive. :-)

One extra variable length identifier is fairly costly.  I've yet to be
convinced that the separate, extra field is necessary.  I see our MIBs
increasingly burdened with table entry gadgets to handle security and
storage and I don't like the trend.  These are global issues that shouldn't
create an extra burden on every entry in every table.

I agree that I'd like to see a common mechanism, so I think you should
remove the extra index.  :-)}

I don't want to back off on this one until we have some real experience
with the two different approaches, to the extent that we can sort out this
aspect from the basic functions of the MIBs.  So what I really believe is
that we should have MIBs representing both mechanisms.

> 4) The description of how access control is to be implemented is way
>    too short. This needs to be spelled out explicitly. For example,
>    how are security credentials used when checking if a notification
>    is to be logged? And what is the value of a null-named log which
>    does not have any security credentials? Is this log always empty?

I'll see what I can do with this.

> 5) The name of the MIB module should be changed from
>    NOTIFICATION-LOG-MIB to DISMAN-NOTIFICATION-LOG-MIB in order to
>    follow our naming conventions.

I think of this as an SNMP infrastructure MIB, not specifically as a DisMan
MIB, so I don't see a good reason to lengthen the name.

> 6) Defining the log size in bytes without defining what this number
>    of bytes means is IMHO pretty useless. 

That's the best argument I've heard yet for removing the byte limit.
Implementations are too different to nail down what it means.

> 7) If we want more than one attribute to limit the size, we should
>    define separate objects and not one object which selects the unit
>    and another which defines the upper limit. That is, if we keep
>    bytes (but see above), than I would like to see an upper limit in
>    bytes and an upper limit in the # of notifications.

You're probably right if I keep the double limit, which I'm more and more
convinced is not the right thing to do.

> 8) The nlmConfigGlobalDataLimit says that this is the number of
>    notifications or bytes that can be held in all named logs. It also
>    says that a particular setting does not guarantee that that much
>    data can be held in the log. So what's the purpose of having this
>    object? And why do we need an aggregated upper limit? If we need
>    it, how is it supposed to work with regard to the other per named
>    log limits? Do I get an error if the sum of the limits for the
>    named logs exceeds the value of nlmConfigGlobalDataLimit? Or do I
>    get an error if the maximum of the the limits for the named logs
>    exceeds the value of nlmConfigGlobalDataLimit? Or do I never get
>    an error (which is what I think the text says)? I propose to
>    remove nlmConfigDataLimitUnits and nlmConfigGlobalDataLimit and to
>    define limits only per named log.

You're right about no errors for a sum of individual limits that exceeds
the global limit.  My intention is for a fairly soft system of limits,
which is why I'm saying there's no guarantee that you can fit the number
you set.  A system may be hopeful and allow a large limit then run out of
dynamic memory and give you a resource error.  I don't want to make the
implementation pain any worse than that.

Likewise for the total of individual limits versus the global limit.  These
are to be guidelines for what you're willing to allow, not hard rules.  I
may want some named logs to have small limits and allow another to take up
all the room if it needs it, starving the others.  I'm playing a
statistical game, not a reservation game.

> 9) The last paragraph in the description of nlmConfigDataLimitUnits
>    and nlmConfigGlobalDataLimit defines conformance requirements. I
>    suggest to move this text out of the object type definition into
>    the conformance definition.

I'll see what I can do about adding it to the conformance section.  I like
to have it in both because people use DESCRIPTIONs as help text.  Sometimes
I neglect the conformance section because I'm not quite sure how to state
the particular situation.

>10) The MIB text is not clear how entries are aged out of the log
>    table. It says that logged notifications are removed if the value
>    of nlmConfigLogControlDataLimit is changed. It does not say what
>    happens if the log fills up.

It's supposed to say that when a log fills up the oldest entries are
deleted in favor of the new ones.  I'll make sure that's there.

>11) I would like to see that logged notifications are removed when
>    either the log fills up or if the logged notification reaches a
>    certain age.

Hmmm.  I didn't want to put in a timer requirement for making things go
away automagically.  I briefly considered a way to flush a log, but then
got worried about the problem of coordination among multiple applications
and am not so sure I should do that either.

>12) The last paragraph in the description of
>    nlmConfigLogControlDataLimit is again a conformance requirement
>    and should be moved to the appropriate section.

See previous comment.

>13) The DEFVAL of createAndWait for nlmConfigLogControlStatus does
>    not make any sense to me.

I'll remove it.

>14) I think the description in nlmConfigLogControlFilterName must
>    be more explicit. How does it deal with received notifications?

I'll look at beefing up the description.

>15) Summarizing issues 6-14, I propose to have a control table which
>    looks like:
>
>    nlmLogCtrlEntry ::= SEQUENCE {
>        nlmLogOwner		SnmpAdminString,
>        nlmLogName		SnmpAdminString,
>	nlmLogCtrlFilter	SnmpAdminString,
>	nlmLogCtrlMaxSize	Unsigned32,	-- max number of notifications
>	nlmLogCtrlMaxAge	TimeInterval,
>	nlmLogCtrlStorageType	StorageType,
>	nlmLogCtrlRowStatus	RowStatus
>    }

I'll have to think about that as I work on editing the details, but I think
you're pushing in a direction I don't want to go.

>16) Typo: Statisitics -> Statistics

OK.

>17) What is the value of having nlmStatsGlobalNotificationsLogged and
>    nlmStatsGlobalNotificationsDiscarded? Is this not just the sum of
>    the statistics in the various named logs? Is a trap which can't be
>    logged but which would otherwise go into several named logs counted
>    more than once?

The value of the grand totals is for easy tracking against the global
limits.  I figure the implementation will need them so they might as well
be available.

As to how the count works for a trap going to several logs, hmmmmm, good
question.  I'm thinking about that....

Got it.  The answer is that the counters relate to their respective limits
and allow implementation flexibility.  In other words what goes in the
global counters is whatever applies to the global limit.  If the
implementation makes multiple copies of a logged trap it counts them
multiple times.  It counts all entries made or bumped out as they apply for
the limit against which they count, so you can see what effect that limit
is having.

Clearly I have to explain that in the MIB.

>18) The two counter that end "..NotificationsLogged" and
>    "..NotificationsDiscarded" do not count notifications that are
>    discarded because there were no resources left. I think this
>    needs to be added or the description of "..NotificationsDiscarded"
>    needs to be changed to cover this situation as well.

OK, I think.

>19) Summarizing issues 17-18, I propose to have a statistics table
>    which looks like:
>
>    nlmLogStatsEntry ::= SEQUENCE {
>        nlmLogStatsLogged	Counter32,
>	nlmLogStatsDiscarded	Counter32, -- discarded due before putting 
>					   -- them into to a log
>	nlmLogStatsPurged	Counter32  -- entries purged during
>					   -- normal operations (aging)
>    }

Hmmm.  The ones discarded cover what I had in mind to cover, that is,
entries you wanted to make but didn't have room.  I don't intend to add
aging in any sense other than deleting the oldest when you need room.  I
don't want to have to add yet more parameters to control that.

If there's a demand for aging we can add it later.

>20) The description of nlmLogEntry does not explain what happens if
>    the log fills up.

I'll add that.

>21) The nlmLogTime object raises an interesting question. For every
>    notification, it is essential to know where it occured and when
>    the notification was raised. Lets assume the log is used to log
>    notifications received from other systems. The time-stamp of the
>    notification is shipped in the varbind list, but it is based on
>    sysUpTime of the sending engine. The nlmLogTime adds a time-stamp
>    when the log entry is generated. However, since both are based on
>    sysUpTime, there is no reliable way to get the date and time when
>    the event really happened. (The time stamp in the recorded varbind
>    list can be ambiguous at the time the value is read from the log.)
>    Changing nlmLogTime to use DateAndTime would help quite a bit to
>    find the real point in time a notification was issued.

Yuk.  I hate problems I can't just wave away.

I'm not happy depending on DateAndTime, since there are still plenty of
systems that don't have that information.

I really don't want to get in the business of interpretation of
sysUpTime-based timestamps in this MIB.  I want it to be usable in a
reasonably low-end system.  My inclination is to push this problem off to
timely use of the logs by higher level applications.

I'm also willing to consider the idea of replacing our sysUpTime-based time
stamps with a variation on DateAndTime that has a clear definition for what
it means on a system that doesn't know the date and time.  In otherwords a
DateAndTime where the well-defined, recognizable degenerate case is a
sysUpTime-based time stamp.  This could be the right way to push all time
stamps and (heh heh) stamp out this debate for all time.

>22) What is the value and the meaning of nlmLogEngineID and
>    nlmLogContextName if I receive a trap from an SNMPv1 agent?

Troublemaker.  Ummmm.  Engine ID is zero (meaningless) and, ummm,
ContextName is the community string from the notification.  How's that sound?

>23) The description of nlmLogNotificationID should probably point to
>    the procedure used to convert RFC 1157 trap identifications into
>    RFC 1905 trap identifications.

OK.

>24) The last sentence in nlmLogEngineID and nlmLogContextName is again
>    a conformance statement and should be moved into the conformance
>    definition.

We're both consistent (sometimes), eh?

>25) The enumeration for nlmLogVariableValueType has an enumeration for
>    "unsignedOrGauge32" but it does not name BITS of INTEGER. So we
>    should either change octetString to bitsOrOctetString and integer32
>    to integerOrInteger32, or we should just use "unsigned32" instead
>    of "unsignedOrGauge32". (I prefer the later one because this is
>    also how the columns in this table are named.)

I'll go for unsigned32 as the enumeration.  Hmmm.  Or should it be gauge32
and make everything consistent with that.  I think perhaps the latter.
What we now call Unsigned32 was Gauge32 first.

>26) I would like to see an example configuration for a named log which
>    shows how a filter is used to setup a log which for example only
>    logs linkUp and linkDown notifications. (This should go into the
>    text and not into the MIB definitions.)

Fair enough.

>27) We need to describe what happens if the configuration itself is
>    inconsistent. For example, the filer name in the log does not
>    refer to an existing filter entry. I guess this results in no
>    notifications logged, but this is not spelled out. Further, I
>    would like to see mechanisms to detect such a configuration
>    problem. (Otherwise, people will setup logs and feel very happy
>    because the logs stay empty, until they recognize that someone
>    else changed the snmpNotifyFilterProfileTable without being aware
>    of the side effects.)

Clarification definitely needed.  As to the requested mechanism, see below.

>28) Finally, I would like to have objects that allow to take a named
>    log out of service without having to worry about the row going
>    away. So I think we should add a pair nlmLogCtrlOperStatus and
>    nlmLogCtrlAdminStatus. These object can also be used to bring a
>    named log automatically into a disabled state once there is no
>    valid filter for this named log.

The disable ability sounds like a good one, and the Oper/Admin approach
nicely answers your previous point, so I'll go for this.

Thanks very much for the detailed consideration of the MIB.

	Bob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Nov 1998 12:37:05 +0100

>>>>> Bob Stewart writes:

>> rules. I strongly suggest to be consistent in our MIBs and to split
>> the name into two parts, like in the Script and Scheduling

Bob> One extra variable length identifier is fairly costly.

Remove nlmConfig, nlmStats and nlmLog and you save the sub-identifier
needed to make the owner index explicit.

Bob> I've yet to be convinced that the separate, extra field is
Bob> necessary.  I see our MIBs increasingly burdened with table entry
Bob> gadgets to handle security and storage and I don't like the
Bob> trend.  These are global issues that shouldn't create an extra
Bob> burden on every entry in every table.

SNMPv3 gave us VACM and we have to use it. I have raised my voice
several times for simpler security stuff but people did not want to
change anything. So we end up with ugly indexes. (I proposed to use
contexts to create security sandboxes but people did not like it,
although nobody could give a reason why it would not work.)

Bob> I agree that I'd like to see a common mechanism, so I think you
Bob> should remove the extra index.  :-)}

Bob> I don't want to back off on this one until we have some real
Bob> experience with the two different approaches, to the extent that
Bob> we can sort out this aspect from the basic functions of the MIBs.
Bob> So what I really believe is that we should have MIBs representing
Bob> both mechanisms.

We obviously do not agree on this point. So we will most likely not
have a common approach within DISMAN.

>> follow our naming conventions.

Bob> I think of this as an SNMP infrastructure MIB, not specifically
Bob> as a DisMan MIB, so I don't see a good reason to lengthen the
Bob> name.

It does not matter for me whether this MIB belongs to the SNMP
infrastructure or not. I am concerned about unique MIB module names
and consistency.

>> either the log fills up or if the logged notification reaches a

Bob> Hmmm.  I didn't want to put in a timer requirement for making
Bob> things go away automagically.  I briefly considered a way to
Bob> flush a log, but then got worried about the problem of
Bob> coordination among multiple applications and am not so sure I
Bob> should do that either.

Well, I see little value in keeping memory resources occupied for
notifications that are more than a month old. This not only costs
memory (and may badly interact with the split of memory resources
between several logs), it also costs time for retrieving log tables
with old entries etc. Its not that hard to go through the log once in
a while to and to throw away those entries that have expired.

>> 15) Summarizing issues 6-14, I propose to have a control table
>> which looks like:
>> 
>> nlmLogCtrlEntry ::= SEQUENCE { nlmLogOwner SnmpAdminString,
>> nlmLogName SnmpAdminString, nlmLogCtrlFilter SnmpAdminString,
>> nlmLogCtrlMaxAge TimeInterval, nlmLogCtrlStorageType StorageType,
>> nlmLogCtrlRowStatus RowStatus }

Bob> I'll have to think about that as I work on editing the details,
Bob> but I think you're pushing in a direction I don't want to go.

Well, the StorageType (whether we like it or not) is important if you
build managers that setting up notification logs. Such a manager must
know whether a configured notification log survives a reboot or not.
Otherwise, the manager has to check the configuration for each device
when it reboots. Not adding StorageType introduces a new management
problem - something we should avoid according to our charter.

>> nlmLogContextName if I receive a trap from an SNMPv1 agent?

Bob> Troublemaker.  Ummmm.  Engine ID is zero (meaningless) and, ummm,
Bob> ContextName is the community string from the notification.  How's
Bob> that sound?

This does not match the MIB proposal in the coexistance document. We
have to make sure that these things are lined up.

>> 25) The enumeration for nlmLogVariableValueType has an enumeration
>> for "unsignedOrGauge32" but it does not name BITS of INTEGER. So we

Bob> I'll go for unsigned32 as the enumeration.  Hmmm.  Or should it
Bob> be gauge32 and make everything consistent with that.  I think
Bob> perhaps the latter.  What we now call Unsigned32 was Gauge32
Bob> first.

Well, it was Gauge first. ;-) I think Unsigned32 is correct. (Gauge32
should have been defined as a TC on top of Unsigned32 in SMIv2, but
this is another story which has passed by.)

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)