[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf PM MIB Issue #9 (fwd)
I have forwared your note to the firstname.lastname@example.org mailing list. You
raise good points but we need to focus on getting the PM done. I have
moved my postings on this subject to the email@example.com list as
well. Juergen is working on longer-term solutions. Lets move the general
discussion to the other list and have SNMPCONF return to a more focused
------- Forwarded Message
Date: Sun, 24 Jun 2001 22:05:57 -0700
From: "David T. Perkins" <firstname.lastname@example.org>
Subject: Re: snmpconf PM MIB Issue #9
On these scalar buttons, I'm assuming that when you guys are really
talking about a collection of objects to implement the button. A
write can take a long time, and it can even fail. So you need at
least the three following objects:
storWrite - action/status object with values:
- write(1), when written starts a write (if one is not
already in progress
- writing(2), read-only value that is returned while
a write to storage is occurring
- failed(3), read-only value that is returned when
the last write to storage failed
- success(4), read-only value that is returned when
the last write to storage succeeded
storIsNewer - read-only object that indicates if "runtime"
newer than stored values
storSerial - testAndSet object that is incremented each time
a write to storage is attempted
Now, you also need to track whether a bulk download from the net
has occurred to storage, which can make the "runtime" and the
stored configuration different.
Please, don't over simplify this problem. There are a few unusual
cases that happen all the time in the real world.
PS I don't see how the "scope of the configuration objects" covered
by a store button can be efficiently specified. (Don't forget
At 07:51 AM 6/21/2001 -0400, Jon Saperia wrote:
>> I believe Juergen's proposal gives the flexibility that the write can be
>> done early but it must be complete by the time the button push is
>> complete in the snmpStorage MIB. In other words, it's like syncing a
>> file system. Prior to the sync the application knows that things *might*
>> have been written to disk but there is no guarantee. The sync can't
>> complete until any unwritten data is written. After the sync the app has
>> a guarantee that the data is written.
>> This adapts to multiple strategies, including:
>> 1) Write to nvram immediately on activating the target row (sync is a
>> 2) Every N seconds, look for unwritten rows and write them (sync only
>> writes rows that have been modified since last interval)
>> 3) Delay writes until sync button is pushed
>> I also agree with Juergen's point that if an agent did #1 for a given
>> target table, it wouldn't necessarily add an entry to the snmpStorage
>> table for that target table. This gives such an agent another option.
>> My main question is, given that there's no way for Juergen's proposal to
>> be standardized before the PM MIB, how do we proceed now? We could:
>> 1) Do nothing and wait for the storage-type MIB to clarify the PM MIB in
>> the same way as it will clarify all other existing use of storageType.
>> (This doesn't add any dependence on the completion of the storage type
>Clarification in another document that does not hold up our work is
>great. There are of course other mechanisms in Juegens proposal that
>will also help - but down the road. For that reason I like your
>> 2) Add a scalar to the PM MIB that writes all nonVolatile entries
>One thing to be clear on about this is that the only changes we are
>talking about are changes within the PM MIB Objects. That is to say we
>are simply writing the objects in the scope of the PM MIB, not waiting
>for configuration changes that might or might not be activated as a
>result of a policy execution. Those objects are defined in other (mostly
>private for now) MIB Objects.
>> Wes Hardaker wrote:
>> > Steve> 2) Add a scalar to the PM MIB that writes all nonVolatile entries
>> > Steve> Comments?
>> > I'm not convinced that forcing this upon the implementer is a "good
>> > thing". It's entirely possible that some implementations will only be
>> > able to write immediately, and others will not be able to write until
>> > some time X later.
>> > I fail to see what the problem is with the existing storage type
>> > mechanisms. If one box must write everything nonVolatile at once and
>> > another one may not, then it is sort of implementation specific as to
>> > what saving methodology is used.
>> > --
>> > Wes Hardaker
>> > NAI Labs
>> > Network Associates
/david t. perkins
------- End of Forwarded Message