Subject: review of draft-ietf-disman-event-mib-05.txt

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Oct 1998 19:14:00 +0100

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

 1) The document has no formfeed characters which makes it a bit
    harder to read the printed version.

 2) Typo in section 5: handlling

 3) Section 5 says: "In the same section the trigger object table
    lists trigger-related objects that can be added to notifications
    either for a trigger or for an event." I am not sure what this
    sentence is trying to tell me.

 4) Section 6 says that local monitoring may "bypass SNMP formatting".
    I think a better phrase would be "bypass SNMP encoding".

 5) Section 6 says that local monitoring is "functionally identical to
    remote SNMP operations". So I guess this means that I have to go
    through access control as well. I think this should be spelled out
    explicitly.

 6) The last paragraph in section 6 is about the decision to rely on
    notifications for error handling. This is indeed against some old
    SNMP principles and I would at least like to know the reasons for
    doing this. This actually requires us to implement the
    notification logging MIB in order to troubleshoot the event MIB.
    I would like to have no such dependencies and to keep the SNMP
    principle unless there is a very convincing reason not to do so.

 7) Section 7 needs more work. I think that just saying that
    credentials (which ones?) are recorded and used to apply access
    control is not enough if we want people to implement it right.

 8) The name of the MIB module should be DISMAN-EVENT-MIB.

 9) Is the choice of 100 for the error codes in the FailureReason TC a
    good one? Note, we used negative enums in the definition of
    SnmpPduErrorStatus in the scheduling MIB. Should we align these
    definitions? What exactly is the meaning of badDestination and
    noAck?

10) It is unclear whether wildcarded triggers adapt themself if
    instances come and go and whether this causes any events to
    be generated.

11) I prefer to use a consistent indexing scheme in all DISMAN MIBs.
    Therefore, I would like to make the prefix of the names explicit
    by adding an mteTriggerOwner to the index.

12) The mteTriggerComment should use SnmpAdminString in order to allow
    UTF8 characters.

13) The description of mteTriggerTest says that mteTriggerValue must
    evaluate to an integer. Note that there is no object type called
    mteTriggerValue. And what does it mean to evaluate to an integer?
    Does it restrict to objects of type Integer32? And if yes, what
    happens to large Unsigned32 values?

14) Should mteTriggerValueID be called mteTriggerVariable? And what
    happens if I put ifTable here?

15) The description of mteTriggerTargetTag says: "Systems limited to
    self management may not accept a non-zero length for the value of
    this object." I think this belongs to the conformance section.

16) The description of mteTriggerTargetTag says: "A length of 0
    indicates the local system.  In this case, access to the objects
    indicated by mteTriggerValueID is under the security credentials
    of the requester that set mteTriggerStatus to 'active'." We should
    probably be explicit here that otherwise the target engine is
    responsible for checking access rights.

17) The text says that mteTriggerContextName can be wildcarded. I have
    no clue how this is going to work.

18) Is there a reason for the upper limit of mteTriggerFrequency?

19) I am confused by the value 0 for mteTriggerFrequency. Can you give
    an example when this is useful or implementable?

20) I am missing objects which allow to take a trigger out of service
    and to enable it later on. The MIB binds the status of a trigger
    to the row status, which means that you can't have a disabled
    trigger for say an hour.

21) I am missing StorageType objects which allow me to put triggers
    into non-volatile memory.

22) The rising and falling thresholds are of type Integer32. This
    means that you can't put a high threshold on Unsigned32 objects.

23) Typo: mteTriggerObjectNName

24) The mteTriggerObjectTable should be indexed by an owner a name.
    It also lacks a StorageType object.

25) How does mteTriggerObjectValueIDWildcard interact with
    mteTriggerValueIDWildcard?

26) What is the purpose of the global failure counters? Should these
    counters not be per row?

27) The mteEventTable should be indexed by an owner a name.
    It also lacks a StorageType object.

28) mteEventComment should be SnmpAdminString instead of DisplayString.

29) The syntax and the defval for mteEventActions is illegal.

30) How does mteEventSetObjectWildcard interact with
    mteTriggerValueIDWildcard and mteTriggerObjectValueIDWildcard?

31) The next to last paragraph in the description of
    mteEventSetTargetTag beloings to the conformance section.

32) mteEventSetContextName says that the context may be wildcarded by
    leaving characters off the end. I don't understand how this works.

33) I don't understand the default value createAndWait for
    mteEventStatus.

34) Typos: mterHotValue, informaation, eventMIBNotificationObjectss

35) The tables defined in this MIB are designed to have lots of holes
    during normal usage. I am not sure whether I like this. It might
    be possible to split tables into a few base tables and some
    extension tables. This will probably also make the structure
    clearer.
							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)

---

From: Bob Stewart <[email-masked]>
Date: Fri, 30 Oct 1998 13:02:54 -0500

>    harder to read the printed version.

The were there when I started.  Looks like something ate them on the way to
the email I sent to internet-drafts.  I'll watch for that next time.

> 2) Typo in section 5: handlling

Will fix.

>    sentence is trying to tell me.

It's just telling you what to expect to see in that section of the MIB.
The explanation of the tables is in the body of the MIB.  I keep rereading
it and can't figure out how to say it any differently.

>    I think a better phrase would be "bypass SNMP encoding".

Much better wording.

>    through access control as well. I think this should be spelled out

You read it correctly.  I'll add "including the application of access control."

>    principle unless there is a very convincing reason not to do so.

The Notification Log MIB is potentially helpful but not really necessary.
The idea as I explained in my earlier reply to Bram is to avoid a large
number of detailed error counts for relatively limited times and value.
The assumption is that you turn on these notifications only while debugging
a problem, then turn them off.  Under such limited circumstances I expect
depending on notifications to be good enough.

To some extent I arrived at this idea due to unhappiness with objects that
record the most recent value of something like an error status.  Those
aren't very useful if you get a pile of errors close together, leading to
the idea of a history, which seemed like serious overkill for error
situations used only for debugging.  Having the Notification Log MIB in
place for other purposes gives this purpose a free ride.

>    control is not enough if we want people to implement it right.

That part intentionally left vague.  :-)}

Would it be close enough if I said you record the security name?

> 8) The name of the MIB module should be DISMAN-EVENT-MIB.

Why?  In some sense it's a long-standing part of the SNMP infrastructure,
dating back to RMON and the Manager-to-Manager MIB.  I don't see any value
in adding DisMan into the name.

>    definitions? What exactly is the meaning of badDestination and

Using negative enums is fine with me.  I'd prefer it.  I haven't
established the habit as the v1 bigots usually whine and whimper when enums
go beyond the v1 rules.

As to aligning definitions, I'm all for it.  I'd like to have one common
textual convention for failures in sending a management message.

You'd get a badDestination if, for example, you supplied a domain name and
it wouldn't translate or if the destination were unreachable.  Adding finer
granularity is a good idea, but I had in the back of my mind to do that in
conjunction with a common textual convention.

The noAck is for a an Inform that didn't get an acknowledgement.  It should
probably be "noResponse".

>    instances come and go and whether this causes any events to

I was used to thinking of wildcards in terms of the Expression MIB, so I
apparently didn't make them clear enough.

They adapt at every sample period, as if you were doing a GetNext with no
history of the previous sample.

As I wrote that I realized that this MIB carries state for threshold
checking and my answer isn't quite good enough.  So the rest of the answer
is that having an instance not present in the current sample when you have
a previous sample causes that potential instance to be quietly forgotten.

>    by adding an mteTriggerOwner to the index.

I prefer not to add an extra index.  I haven't been convinced that simply
using names as indexes is not sufficient.

>12) The mteTriggerComment should use SnmpAdminString in order to allow

I disagree.  I won't change that unless we establish a broad policy that
all textual fields are UTF8 and establish an appropriate replacement for
DisplayString.

>    happens to large Unsigned32 values?

I believe I picked up that language from RMON.  It boils down to anything
that gets encoded in BER as an integer, regardless of the SNMP data type,
so it includes, for example, Integer32, Unsigned32, and TimeTicks, but not
OCTET STRING or IpAddress.

It's supposed to be referring to mteTriggerValueID.

>    happens if I put ifTable here?

I guess it could be mteTriggerVariable.  I tend not to use the word
"variable" much when talking about SNMP.  It always seemed to me like we
had too many words that meant too close to the same thing.

If you put ifTable there and leave mteTriggerValueIDWildcard false, you'll
never get a trigger because the object will never exist.

If you set mteTriggerValueIDWildcard true, you're likely to get bizarre
results depending on the implementation as it GetNexts its way through the
whole ifTable trying to apply your test to everything in it.  Or, if the
implementation can tell you're not out into instance space in the OID, it
could refuse to accept the OID in the first place.

>    this object." I think this belongs to the conformance section.

It is.  Given that DESCRIPTIONs are often used as documentation it seems
helpful to say it there, too.

>    responsible for checking access rights.

OK.

>    no clue how this is going to work.

It assumes the system has a list of remote or local contexts that it can
wildcard the same way that OIDs are wildcarded.  The idea is to be able to
apply a trigger across a set of related contexts without needing an
otherwise trigger entry for each one.  An example would be getting objects
from wildcarded context Repeater, which would match Repeater1, Repeater2,
and so on.

>18) Is there a reason for the upper limit of mteTriggerFrequency?

Not really, other than letting you save a couple of bytes in internal
storage.  If I made it Unsigned32 I wouldn't even need a range.  Would you
like that better?

>    an example when this is useful or implementable?

This is for situations where the sensing of the trigger is or can be
embedded very near the monitored value.  That's how you'd model using this
MIB to implement standard notifications, which go off right when the
criteria are met rather than waiting for the next sample interval to come
around.

I added this due to a suggestion made on the mailing list some time ago.
It's not a capability I'd expect most systems to have, but it recognizes
the concept of being interrupt driven rather than polling driven.

>    to the row status, which means that you can't have a disabled

Hmmmm.  That sounds like a good idea.  I'll add it.  Would you like the
DEFVAL to be on or off?  I'm inclined to say on.

>    into non-volatile memory.

This is one of those areas where I need a guiding principle.  We seem to be
backing into the idea of StorageType everywhere and I don't really like
that model.  How do we decide which MIBs should have it and which shouldn't?

I'd say most shouldn't and whether the configuration gets saved or not, and
how, depends on the characteristics of the overall implementation (which is
the case with most MIBs already).

>    means that you can't put a high threshold on Unsigned32 objects.

I think I copied that from RMON.  If I make it Unsigned32 then you can't
set negative thresholds.  I really don't want to have multiple objects for
this.

I'm inclined to say that allowing negative and having the Integer32 range
is enough.  Numbers in the Unsigned32 range seem so big they're fairly
meaningless.

>23) Typo: mteTriggerObjectNName

OK.

>    It also lacks a StorageType object.

See previous philosophical comments.

>    mteTriggerValueIDWildcard?

For a given instance of a trigger occuring the wildcard is filled by the
same value for that instance.  So, for example, if you were wildcarding the
ifIndex part of an OID you could include ifIndexed objects in the resulting
notification.  Same deal as for mteEventSetObjectWildcard.

>26) What is the purpose of the global failure counters? Should these

I think I covered that sufficiently in my responses to Bram.

>    It also lacks a StorageType object.

See previous philosophy.

>28) mteEventComment should be SnmpAdminString instead of DisplayString.

See previous philosophy.  (We're both consistent, eh?)

>29) The syntax and the defval for mteEventActions is illegal.

You mean I can't make up my own way to do BITS?  I guess I'll have to do it
the standard way.

>    mteTriggerValueIDWildcard and mteTriggerObjectValueIDWildcard?

Answered above.

>    mteEventSetTargetTag beloings to the conformance section.

See previous comment on similar situation.

>    leaving characters off the end. I don't understand how this works.

The idea is as if you specified "Repeater*" where you expect something like
a number on the end.  The idea is to limit this to a trailing wildcard,
which works nicely with GetNext-style processing.

>33) I don't understand the default value createAndWait for

I'll remove it.  Keith has straightened me out on the underlying issue.

>34) Typos: mterHotValue, informaation, eventMIBNotificationObjectss

That was to make them look like Dutch, but I guess I can fix them.

>    extension tables. This will probably also make the structure

I'm generally in favor of that approach so I'll give it serious thought.
The MIB sort of grew organically over time and I didn't realize how much
that had happened.

Thanks for the comments.   They'll help make this a better, more clear MIB.
 I expect we'll be discussing the philosophical issues here so I'll know
what I should do about them.

	Bob