Subject: Re: Responses to comments on the Event MIB

From: Frank Strauss <[email-masked]>
Date: 23 Oct 1999 22:58:19 +0200

Hi!

>> Furthermore, SMICng gives me these errors/warning: [...]

>> E: f(event.mi2), (304,14) Default value for "mteTriggerTest" must be
>> named bits in "{ }"
>> E: f(event.mi2), (1236,14) Default value for "mteEventActions" must be
>> named bits in "{ }"

Ram> The last two errors about the DEFVAL also sound incorrect to me,
Ram> but maybe I'm mistaken?
 
BITS DEFVALs must have double pairs of braces. The outer pair belongs to
the DEFVAL construct, the inner pair is needed for a BITS value.

>> W: f(event.mi2), (1066,29) Row "mteObjectsEntry" does not have a consistent
>> indexing scheme - all index items for "base row"
>> mteTriggerEntry must be specified
>> W: f(event.mi2), (1193,37) Row "mteEventEntry" does not have a
>> consistent indexing scheme - all index items for
>> "base row" mteTriggerEntry must be specified

>> I guess the warnings are a Perkins-ism, pls confirm if you think so too.
>> I can make the compiler silent about the wngs, but the errors need fixing.

Ram> [...] - the warnings don't make sense to me...

Well, I'm not yet very familiar with the Event MIB. Anyway, I wonder,
why the mteObjectsTable and mteEventTable express a somehow partial
relation to the mteTriggerTable by using its mteOwner column instead
of own columns. How do you think about renaming mteOwner to
mteTriggerOwner and adding non-accessible mteObjectsOwner to the
mteObjectsTable and mteEventOwner to the mteEventTable, just as usual?

To refer the standards: I think, RFC 2578 7.8.1-(3) is not sufficiently
clear about this question:

  (3)  Otherwise, if no existing objects have the required syntax and
       semantics, then auxiliary objects should be defined within the
       conceptual row for the new table, and those objects should be used
       within the INDEX clause for the conceptual row.

It doesn't say something about wheather only some appropriate objects
might be used and what exactly is meant by `required semantics'. This
is what Perkins blames in http://www.snmpinfo.com/tables.pdf.

 Frank

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Oct 1999 11:10:22 +0200

>>>>> Frank Strauss writes:

Frank> Well, I'm not yet very familiar with the Event MIB. Anyway, I
Frank> wonder, why the mteObjectsTable and mteEventTable express a
Frank> somehow partial relation to the mteTriggerTable by using its
Frank> mteOwner column instead of own columns. How do you think about
Frank> renaming mteOwner to mteTriggerOwner and adding non-accessible
Frank> mteObjectsOwner to the mteObjectsTable and mteEventOwner to the
Frank> mteEventTable, just as usual?

[...]

Some WG members recommended to do this but the former editor of this
document did reject those changes, probably because he believes that
it does not change anything on the wire and hence it does not matter
how we model table relationships.

(There has also been concerns about how the MIB is generally
structured and whether the many inter-table relationships are really
needed. It turned out that I had disagreement about this with the
former editor of the MIB and that nobody else spoke up or cared about
the issue. So I gave up on it - but the issues are well documented in
the archives.)

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>