Subject: Re: New Notification Log MIB Draft

From: Bob Stewart <[email-masked]>
Date: Wed, 04 Nov 1998 17:12:42 -0500

At 09:43 AM 10/13/98 -0400, Martin Bjorklund wrote:
>What do you mean by "hierarchically structured log names"?

Randy covered this one.

>> nlmConfigDataLimitUnits OBJECT-TYPE
>
>I have some problems with the global Units vs the global and local
>limits.  The problem is that I don't understand what's supposed to
>happen if a manager changes the value from say 'notifications' to
>'bytes'.  Are all *limit objects automatically recalculated?

I put this business in because someone requested it.  I'm becoming
convinced it's not worth the complexity.  Unless someone talks me out of it
I'm going to change the limit back to being on the basis of the number of
notifications and forget the idea of doing it by bytes.

>> nlmConfigGlobalDataLimit OBJECT-TYPE
>
>The DESCRIPTION clause still talks about "the log", which I guess is
>just some old text from the old draft.

Yup, that should be the sum of all the named logs.

>> nlmConfigLogControlFilterName OBJECT-TYPE
>>     SYNTAX     SnmpAdminString (SIZE(0..32))
>>     MAX-ACCESS read-create
>>     STATUS     current
>>     DESCRIPTION
>>         "A value of snmpNotifyFilterProfileName from the SNMP
>
>I've said this before: using snmpNotifyFilterProfileName implies an
>entry in the snmpNotifyFilterProfileTable, which implies an entry in
>snmpTargetParamsTable.

I went back and studied the tables and I don't agree about the implication.

My understanding of the tables is that you can have an entry in the
snmpNotifyFilterTable without having one in any other.  The index objects
for snmpNotifyFilterTable are snmpNotifyFilterProfileName and
snmpNotifyFilterSubtree.  The OBJECT-TYPE macro associated with
snmpNotifyFilterProfileTable defines snmpNotifyFilterProfileName but makes
no implication that there must be a value in snmpNotifyFilterProfileTable
to match any given value used as an index in snmpNotifyFilterTable.

I could be persuaded that I'm not saving anything by using that table from
the Notification MIB or that my table really should enable the logging of
particualar notifications rather than filter, but as I have it there is no
dependence on snmpTargetParamsTable or snmpNotifyFilterProfileTable.

>Some of the objects have default values defined in the DESCRIPTION
>clasuse.  These should probably be moved to DEFAULT clauses.

Are those in the tables or are they scalars?  Strict interpretation of the
standard says we're not supposed to put DEFVALs on scalars.

>This one is really less important, but maybe the name
>'nlmConfigLogControlTable' could be made less confusing, e.g. just
>'nlmLogControlTable' or 'nlmConfigLogTable'?

I'll think about that.  I was trying to use a consistent prefix within that
section of the MIB.

Thanks for all your interest and comments.  You've been quite helpful.

	Bob

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Nov 1998 09:12:43 -0500

> to match any given value used as an index in snmpNotifyFilterTable.

Yes you're right.  I got confused because I thought that the
nlmConfigLogControlFilterName refered to a value in
snmpNotifyFilterProfileTable, when it actually refers to a value in
snmpNotifyFilterTable.  Maybe you could add some text to the
DESCRIPTION that describes this unambiguously?  For example, 

        "A value of snmpNotifyFilterProfileName from
        snmpNotifyFilterTable, defined in the SNMP
        Notification MIB, specifying the Notifications to be
        filtered out and not logged in this named log.

I noted that RFC1902 says that:

   Note that objects specified in a conceptual row's INDEX clause need
   not be columnar objects of that conceptual row.  In this situation,
   the DESCRIPTION clause of the conceptual row must include a textual
   explanation of how the objects which are included in the INDEX clause
   but not columnar objects of that conceptual row, are used in uniquely
   identifying instances of the conceptual row's columnar objects.

Such a textual explanation is not present in snmpNotifyFilterTable,
which makes it unclear how it should be used.  But I guess (hope) it's
ok to interpret the absence in this way.

> standard says we're not supposed to put DEFVALs on scalars.

Right.  But the latest draft from the SMIv2 team also says that:

  Note that with this definition of the DEFVAL clause, it is appropriate    |
  to use it for any columnar object of a read-create table.  It is also     |
  permitted to use it for scalar objects dynamically created by an agent,   |

How should this be interpreted?  In our agent implementation, *all*
objects can be viewed as being dynamically created, because MIBs are
loaded into the agent during run-time.  Since such an implementation
always is feasible, all scalars could have a DEFVAL clause, couldn't
they?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Nov 1998 15:47:24 +0100

>>>>> Martin Bjorklund writes:

Martin> Right.  But the latest draft from the SMIv2 team also says
Martin> that:

: Note that with this definition of the DEFVAL clause, it is appropriate    |
: to use it for any columnar object of a read-create table.  It is also     |
: permitted to use it for scalar objects dynamically created by an agent,   |
: or for columnar objects of a read-write table dynamically created by an
: agent.

Martin> How should this be interpreted?  In our agent implementation,
Martin> *all* objects can be viewed as being dynamically created,
Martin> because MIBs are loaded into the agent during run-time.  Since
Martin> such an implementation always is feasible, all scalars could
Martin> have a DEFVAL clause, couldn't they?

The main purpose of the DEFVAL clause at the time it was invented was
to define the value for columnar objects during row creation when no
explicit value was provided during row creation. Enough people argue
now that the usage of DEFVAL is also handy for scalars that are
dynamically created and the text in the new draft reflects this view
of the community. 

(Note that this usage of DEFVAL serves a different purpose and has
implications especially on agent toolkits. However, this issue has
been discussed at some length at the SMI BOF in Chicago - the SMI-DT
just tried to document the concensus in Chicago.)

Keith and I still believe that there is an important conceptual
difference between columnar objects that are designed to be
dynamically created and scalar objects that are typically created
during (sub)agent startup. But we do not think that this issue is
important enough to start lengthy discussions and to hold of the SMIv2
from progressing to full standard. The agent toolkit vendors at the
SMIv2 BOF did agree to the new interpretation and this is probably
the most important voice in this issue.
							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: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Nov 1998 09:59:10 -0500

Juergen Schoenwaelder <[email-masked]> wrote:
> explicit value was provided during row creation.

> Enough people argue

Yes, but how can a MIB designer tell if the agent in which the MIB is
implemented loads the MIB dynamically?  (and thus creates the objects
dynamically).  I'd say he can't, and therefore the text in the draft
can be interpreted as allowing DEFVAL for any scalar.

Bob Natale <[email-masked]> wrote:
>Should I use DEFVAL even for scalars?

Bob> I wish we (collectively) would.  Granted, the role DEFVAL
Bob> plays in the case of creatable columnar objects that are
Bob> omitted from a Set that instantiates a row is clear and
Bob> does not literally apply to scalars.  However, using DEFVAL
Bob> clauses as a somewhat structured way of identifying default
Bob> values the agent might apply to any object seems like a
Bob> sensible and handy form of documentation that does nothing
Bob> to harm the role of DEFVAL for creatable columnars...IMHO.

I definitely agree!

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Nov 1998 17:12:21 +0100

>>>>> Martin Bjorklund writes:

Martin> Yes, but how can a MIB designer tell if the agent in which the
Martin> MIB is implemented loads the MIB dynamically?  (and thus
Martin> creates the objects dynamically).  I'd say he can't, and
Martin> therefore the text in the draft can be interpreted as allowing
Martin> DEFVAL for any scalar.

Yes, this is what the text says. 

I just tried to explain that some of us believe there is a difference
between creating instances at initialization time (and dynamically
loading a MIB module implementation is still the initialization time
of the MIB module) and creating instances during explicit management
operations. 

Anyway, I think the text says what you and the WG wants and there is
little value in continuing this dicussion now.

							Juergen