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

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 19 Oct 1998 12:31:28 +0200

Here are my comments for <draft-ietf-disman-notif-log-mib-04.txt>. I
am not reporting any syntactic errors that have already been reported
by others.

 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.

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

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

 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?

 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.

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

 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.

 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.

 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.

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.

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.

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

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

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

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
    }

16) Typo: Statisitics -> Statistics

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?

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.

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)
    }

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

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.

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

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

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

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

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

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

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.

							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)