Re: snmpconf PM MIB Issue #9 (fwd)

[Jon Saperia <saperia@jdscons.com>]

David,

I have forwared your note to the mibs@ops.ietf.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 mibs@ops.ietf.org 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
discussion.

Thanks.
/jon
------- Forwarded Message

Date:    Sun, 24 Jun 2001 22:05:57 -0700
From:    "David T. Perkins" <dperkins@dsperkins.com>
To:      snmpconf@snmp.com
Subject: Re: snmpconf PM MIB Issue #9 

HI,

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
    about contexts.)

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
>> no-op)
>> 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
>> MIB).
>
>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
>suggestions #2.
>
>> 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.
>/jon
>
>> 
>> Steve
>> 
>> 
>> 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
>> 
>
>Thanks,
>/jon

Regards,
/david t. perkins



------- End of Forwarded Message