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

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

>>>>> Bob Stewart writes:

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

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

Well, a guy from Twente also got confused why there is a "link" to the
trigger object table in both the trigger and the event table. It would
probably help to explain the purpose of this construction somewhere.

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

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

I have problems to agree with you here. I am not convinced that
problems only show up while configuring the event MIB. Think about the
failure codes in the FailureReason TC. I am also not sure that the
number of counters needed is so huge to throw a working MIB design
principle away. Also, these counter objects are so easy to implement
(just a ++ at the right place) that I have doubts you save anything by
using notifications.

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

Counters are great to detect that there is a problem. If you want
more, you usually define objects to hold information about the last
error. If you want even more, you define notifications which include
send these error objects when the problem shows up. The advantage of
this approach is that you can detect error situations without having
to listen to notifications. I am still missing the convincing reason
why the event MIB needs to use a new mechanism.

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

Bob> That part intentionally left vague.  :-)}

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

No, this does not cut it. The reason why we do not support sets on
remote variables in the scheduling MIB is because we were not able to
figure out how to delegate credentials. Storing the security name is
not enough if you SNMPv3 with authentication and privacy. There is a
hard security related problem here and I think that just leaving it
"vague enough" is the wrong way. (I would have serious doubts that
this passes the security review.)

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

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

MIB module names must be unique. Using EVENT-MIB has a high
propability to clash. Calling it DISMAN-EVENT-MIB has a much lower
propability to clash. Sure, an even better name would be
IETF-DISMAN-EVENT-MIB, but people in the IETF are still not ready to
accept names like this. The MIBs produced by the SNMPv3 are now
prefixed and at least two of the DISMAN MIBs are prefixed. This is a
good sign and we should continue this path. (It does not matter if the
ideas in this MIB are rooted in other WGs as the DISMAN WG is now
responsible for this MIB.)

(Bob, I thought you are a great fan of hierarchical names. ;-)

>> 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?

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

The snmpTargetAddrTable uses TAddress and TDomain to specify transport
addresses. Right now, there is no TDomain defined which allows to use
a DNS name. So I am wondering whether we really need badDestination.

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

Obviously, I prefer noResponse.

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

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

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

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

In some cases, an instance going away might be an interesting event
itself. So the only way to detect changes in a table is to use non
wildcarding entries for each row, which means that we might end up
with pretty large tables, right?

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

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

Using simple names means overloading of two different concepts. SNMP
history is full of things that used overloading and which turned out
to be problems later on. So we should not do the same mistakes again.
And I don't see the big costs involved.

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

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

I think this is a post-it object which is only provided to make the
life of the human user of this MIB easier. I think there are clear
IETF rules about internationalization in this case and there is little
left to discuss. (How to you explain people that they can use umlauts
in the index but not in the comment?)

>> 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?

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

I think this must be spelled out in the document.

Bob> It's supposed to be referring to mteTriggerValueID.

OK.

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

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

Yep.

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

We need to specify the rules. Leaving it to the implementor to pick
what he thinks is best will cause serious problems on the manager side
because managers will not interoperate with different agent
implementations.

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

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

The SMIv2 allows to have more than one compliance statement for a MIB
module. Repeating compliance statements in the description is
therefore a bad idea as it prevents to define a more strict compliance
level later on. It is generally a good style to specify things only in
one place because this will automatically keep definitions consistent.

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

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

If we do this, we need to specify explicitely which contexts are used
to match the prefix. Are the contexts taken from the vacmContextTable?
Or is this again something the implementor can decide to implement in
whatever way he likes to do it?

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

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

Yes.

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

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

I prefer off. :-)

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

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

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

I disagree. A manager who creates an entry needs to know whether the
entry will survive a reinitialization of the agent or not. The
StorageType TC is probably not the ultimate solution - but this is the
only standards track mechanism we got. So we should use it. Leaving it
up to the implementor does not work for management application writers.

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

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

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

I do not believe that large numbers are less meaningful than small
numbers. There is an important design decision here and I would like
to hear more opinions whether it is enough to use Integer32 for
thresholds. (Note that we have Counter64 in SMIv2 and people are
frequently asking for Integer64 and Unsigned64. Limiting us to
Integer32 may turn out to be a serious problem in say two years from
now.)

>> 25) How does mteTriggerObjectValueIDWildcard interact with
>> mteTriggerValueIDWildcard?

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

Yes, this is what I understood how it works. I will rephrase my
question: What happens if mteTriggerValueIDWildcard is true and
mteTriggerObjectValueIDWildcard is set to false and the other way
round. I guess such a set should fail. Its usually helpful if we spell
out cases like this and document the error codes to be returned in
order to avoid interoperability problems.

>> 30) How does mteEventSetObjectWildcard interact with
>> mteTriggerValueIDWildcard and mteTriggerObjectValueIDWildcard?

Bob> Answered above.

See response to your answer above. :-)
							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, 13 Nov 1998 17:55:01 -0500

>probably help to explain the purpose of this construction somewhere.

I'll see what I can do.

>>> notifications for error handling.

I've attempted to start a meta-discussion on this one to help decide.

>this passes the security review.)

OK.  I should have said you need the parameters for the isAccessAllowed
function from the Architecture document (RFC 2271).  For local access,
whether get or set, that information recorded for the trigger's creator
should be sufficient.  It doesn't allow all possible models, but it allows
a useful model without getting complex.

For remote objects the remote system is picked with a tag that keys into
the Management Target information.  If that's not sufficient for at least a
reasonable set of useful situations, then the Management Target setup
didn't accomplish part of exactly what I wanted it for.

I guess I should have said that in the first place, eh?

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

I'll yield on this only if the working group makes it a requirement for all
MIBs in the working group.  And I'll argue about it first.

>propability to clash.

Clash with what?  Somebody's proprietary MIB?  They're the ones that
shouldn't be using names that sound like standard MIBs.  At Xyplex and
Cisco I've made a point of the company name going on the front of
enterprise MIBs.  No other IETF working group should have the nerve to
define something with so generic a name as Event MIB.  So what's left to
conflict?

>(Bob, I thought you are a great fan of hierarchical names. ;-)

Yup.  And I believe in short names at the top of the hierarchy, which is
where I believe we are.

>a DNS name. So I am wondering whether we really need badDestination.

You still need badDestination for unreachability.  And I'd still like to do
this as a common textual convention that might have more codes than a
specific application or situation might need.

>with pretty large tables, right?

Detecting table entries coming and going is an interesting problem and the
structure as I have it doesn't cover that.

I could add a new type of trigger for table entry creation or deletion as a
third option along with boolean and thresholds.  The trigger could be for
creation, deletion, or both.  If applied to creation of a non-wildcard it
would fire when that object appeared or if for deletion when it
disappeared.  For a wildcard it would trigger as appropriate for things
coming and going from the list of existing objects satisfying the wildcard.

>And I don't see the big costs involved.

We also have some history of making things so complex that people wouldn't
implement them.

>in the index but not in the comment?)

I started a separate thread about this, and Keith confirmed my recollection
that SnmpAdminString was not intended for this sort of use.  I believe we
need a new textual convention for international DisplayStrings and a policy
for switching to its use.

>I think this must be spelled out in the document.

Will do.

>because managers will not interoperate with different agent

I don't think we can specify a much better rule that will work in all
*agent* environments.  Agents don't have all the information that's in the
MIB.  That's why a wildcard flag is needed.  Agents can't tell a broken OID
from a short-terminated one.

The problem is not one of interoperation with reasonable settings in the
MIB.  It's one of what happens when you put in garbage.  I'm just saying
you get out garbage and not specifying what that garbage has to look like
or that I can even tell you put garbage in.

>one place because this will automatically keep definitions consistent.

I generally agree with putting things in one place, but I'm concerned that
people look for significant information in the DESCRIPTION and I hate to
leave it out of there.

>whatever way he likes to do it?

The contexts are all the contexts known to that SNMP engine.  I don't want
to depend on the VACM table, since this MIB should be able to work without it.

>Bob> like the DEFVAL to be on or off?  I'm inclined to say on.

Talked me into it.

>up to the implementor does not work for management application writers.

A manager that sets *any* MIB variable needs to know if that's volatile or
not.  StorageType isn't the answer and I seriously dislike the way it's
proliferating.

>Integer32 may turn out to be a serious problem in say two years from

I believe that thresholds are most likely to be used for differences, not
absolute numbers, and in that case the Integer32 range seems sufficient to
me.  Remember, thresholds are for moving numbers and differences of more
than an Integer32 just don't sound very interesting.

If that doesn't work out, there's the Expression MIB.  :-)}

>order to avoid interoperability problems.

Ahh.  I see.  You're right.  That operation needs to be specified.  I
wouldn't make incompatible values a failure because that creates an
interdependency as to what you change first.  I'll be explicit about how it
operates.  It's too late of Friday to figure it out right now.

	Bob

---

From: Mike Daniele <[email-masked]>
Date: Mon, 16 Nov 98 10:58:22 -0500

>>probably help to explain the purpose of this construction somewhere.

Some text on how to place the objects in the pdu would certainly help.

Other general comments:

1) There is an implied state for each trigger. once a threshold has been  
   reached, events aren't generated until the value falls below the other
   threshold.

   Why not make this state visible?  It seems like it would be useful to be
   able to view the trigger's current state (for example, "set" vs "reset"), 
   and the agent has to implement state per trigger anyway.

2) It appears to be necessary to implement some amount of the expression mib
   in order to implement common comparisons.  Using the event mib alone,
   one could create these triggers:

	o value of object instance is not 0
	o value of object instance is >= rising threshold
	o value of object instance is <= falling threshold

   There is no way to indicate delta evaluation, or =, >, or <
   comparisons, except by doing so within the expression mib.

   I think it would be helpful to state this in the mib text somewhere.

   I also think it would be reasonable to extend this mib just a little
   to permit creating those other types of triggers.  It just seems  like
   requiring the agent to implement parsing and the expression mib, just to
   set up a delta threshold, is a little much.

3) Textual clarifications:

   mteTriggerTest refers to mteTriggerValue.  There is no such object.

   mteTriggerValueID refers to mteTriggerIDWildcard, should be mteTriggerValueIDWildcard.

   mteTriggerRisingEvent and FallingEvent say "A value of 0 indicates no event".
   Should be a length of 0, as in mteTriggerEvent.

   mteTriggerObjectID OBJECT-TYPE
   ------------------

Should be mteTriggerObjectValueID

    SYNTAX      OBJECT IDENTIFIER
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "The object identifier of a MIB object to add to a Notification
        that results from the firing of a trigger.

        This may be wildcarded by truncating all or part of the
        instance portion, in which case the instance portion of the
        OID for obtaining this object will be the same as that used
        in obtaining the mteTriggerObjectValueID that fired.
			 -----------------------
I think this should be mteTriggerValueID.

        If such wildcarding is applied, mteTriggerObjectIDWildcard
				        --------------------------
        must be 'true' and if not it must be 'false'."

And this should be mteTriggerObjectValueIDWildcard.

Regards,
Mike

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 17 Nov 1998 11:33:02 +0100

>> remote variables in the scheduling MIB is because we were not able
>> to figure out how to delegate credentials. Storing the security
>> name is not enough if you SNMPv3 with authentication and
>> privacy. There is a hard security related problem here and I think
>> that just leaving it "vague enough" is the wrong way. (I would have
>> serious doubts that this passes the security review.)

Bob> OK.  I should have said you need the parameters for the
Bob> isAccessAllowed function from the Architecture document (RFC
Bob> 2271).  

This is what I have in mind.

Bob> For local access, whether get or set, that information recorded
Bob> for the trigger's creator should be sufficient.  

Right.

Bob> For remote objects the remote system is picked with a tag that
Bob> keys into the Management Target information.  If that's not
Bob> sufficient for at least a reasonable set of useful situations,
Bob> then the Management Target setup didn't accomplish part of
Bob> exactly what I wanted it for.

The problem is that you need to store credentials (keys) in order to
talk to remote systems and I am not sure we do have a working solution
for that. The target MIB pushes this problem away by only defining the
security name, security model and the security level. So you end up
looking into the usmUserTable. This one indicates that you can have
entries for engineIDs that are not local. Whether the KeyChange
mechanism really works in such a setup remains to be demonstrated.

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

Bob> I'll yield on this only if the working group makes it a
Bob> requirement for all MIBs in the working group.  And I'll argue
Bob> about it first.

If I had the power, I would indeed make this a requirement for all
MIBs in this working group. If I would have even more power, I would
probably establish an even stronger rule for all IETF MIBs.

>> MIB module names must be unique. Using EVENT-MIB has a high

Bob> Clash with what?  Somebody's proprietary MIB?  They're the ones
Bob> that shouldn't be using names that sound like standard MIBs.  At
Bob> Xyplex and Cisco I've made a point of the company name going on
Bob> the front of enterprise MIBs.  No other IETF working group should
Bob> have the nerve to define something with so generic a name as
Bob> Event MIB.  So what's left to conflict?

Sure, the SMIv2 states that developers of enterprise information
modules are encouraged to choose names for their information modules
that will have a low probability of colliding with standard or other
enterprise information modules. (I am not so sure if there is such a
statement in SMIv1.) The question is whether the IETF should act as an
exemplary or not. It took the IETF years to understand how to choose
reasonable module names and we now expect that every company (they
usually starts from IETF modules) does it right from the beginning? I
strongly believe that the IETF should demonstrate how to choose good
names rather then hoping that everyone else chooses better names. Your
position that everyone else has to choose good names so that the IETF
WGs can continue to pick what they like seems odd to me and does not
match my expectations of the IETF being a club of engineers who
demonstrate how to do things right.

>> (Bob, I thought you are a great fan of hierarchical names. ;-)

Bob> Yup.  And I believe in short names at the top of the hierarchy,
Bob> which is where I believe we are.

I don't see the big value of short module names. I see however the
costs associated with name clashes and I am convinced that the price
for a slightly longer but more likely unique module name is a fair
trade-off wrt the problems such a longer name helps to avoid.

>>>> 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
>>  The snmpTargetAddrTable uses TAddress and TDomain to specify
>> transport addresses. Right now, there is no TDomain defined which
>> allows to use a DNS name. So I am wondering whether we really need
>> badDestination.

Bob> You still need badDestination for unreachability.  And I'd still
Bob> like to do this as a common textual convention that might have
Bob> more codes than a specific application or situation might need.

You want to distinguish between noResponse and badDestination? Do you
want to put in a requirement that the implementation has to listen to
ICMP reports? Or how do you distinguish between noResponse and
badDestination?

>>  We need to specify the rules. Leaving it to the implementor to
>> pick what he thinks is best will cause serious problems on the
>> manager side because managers will not interoperate with different
>> agent implementations.

Bob> I don't think we can specify a much better rule that will work in
Bob> all *agent* environments.  Agents don't have all the information
Bob> that's in the MIB.  That's why a wildcard flag is needed.  Agents
Bob> can't tell a broken OID from a short-terminated one.

The current draft does not even say what a broken OID is and what not.
I mean, you can make a walk even if you don't know the table
boundaries. The question is how you deal with data types that do not
apply for the tests. Or you could say that instances returned in the
getnext sweep have to be the same object type (sure, this requires MIB
knowledge). I still believe that we have to define what the behaviour
should be. Leaving this undefined will result in lots of different
implementations and this will make it a nightmare to write management
applications.

Bob> The problem is not one of interoperation with reasonable settings
Bob> in the MIB.  It's one of what happens when you put in garbage.
Bob> I'm just saying you get out garbage and not specifying what that
Bob> garbage has to look like or that I can even tell you put garbage
Bob> in.

I am not so sure the MIB does say what is garbage and what not. This
is what causes my concerns. If you add a clear statement (or point me
to the statement I have missed) what garbage means in the context of
wildcarded OIDs, I would be happy.

>> The SMIv2 allows to have more than one compliance statement for a
>> MIB module. Repeating compliance statements in the description is
>> therefore a bad idea as it prevents to define a more strict
>> compliance level later on. It is generally a good style to specify
>> things only in one place because this will automatically keep
>> definitions consistent.

Bob> I generally agree with putting things in one place, but I'm
Bob> concerned that people look for significant information in the
Bob> DESCRIPTION and I hate to leave it out of there.

If it were true that people do not read the conformance statements,
then why do we define conformance statements at all? Once again,
putting conformance requirements into the DESCRIPTION makes it very
hard to express different conformance levels. We should not make this
mistake and instead use the mechanisms defined in the SMI to express
conformance requirements.

>>  If we do this, we need to specify explicitely which contexts are
>> used to match the prefix. Are the contexts taken from the
>> vacmContextTable?  Or is this again something the implementor can
>> decide to implement in whatever way he likes to do it?

Bob> The contexts are all the contexts known to that SNMP engine.  I
Bob> don't want to depend on the VACM table, since this MIB should be
Bob> able to work without it.

I am concerned that a manager can't figure out what a wildcard
actually resolves to.

>> I disagree. A manager who creates an entry needs to know whether
>> the entry will survive a reinitialization of the agent or not. The
>> StorageType TC is probably not the ultimate solution - but this is
>> the only standards track mechanism we got. So we should use
>> it. Leaving it up to the implementor does not work for management
>> application writers.

Bob> A manager that sets *any* MIB variable needs to know if that's
Bob> volatile or not.  StorageType isn't the answer and I seriously
Bob> dislike the way it's proliferating.

The StorageType column usually defines the storage type of all
configurable objects in a row. This is used in all the SNMPv3 MIBs. I
don't care whether you like StorageType or not. I do care about
managers that need to know whether a row survives a reboot or not.

>> numbers. There is an important design decision here and I would
>> like to hear more opinions whether it is enough to use Integer32
>> for thresholds. (Note that we have Counter64 in SMIv2 and people
>> are frequently asking for Integer64 and Unsigned64. Limiting us to
>> Integer32 may turn out to be a serious problem in say two years
>> from now.)

Bob> I believe that thresholds are most likely to be used for
Bob> differences, not absolute numbers, and in that case the Integer32
Bob> range seems sufficient to me.  Remember, thresholds are for
Bob> moving numbers and differences of more than an Integer32 just
Bob> don't sound very interesting.

Several years ago, people thought that 32 bit numbers are enough.
Later, they added Counter64 but they could not find a reason why other
64 bit numbers might be needed. Now we are having endless discussions
on how to add the remaining 64 bit numbers without breaking too
much. Sure, the thresholds you can think of now may all be in the
signed Integer32 range. Whether this is still true with 100 GBit
networks in a few years remains to be seen.
							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)