Re: guidelines 4.6.2/4.6.3 (persistence of values of read-writeobjects)

["C. M. Heard" <heard@pobox.com>]

[ in reply to comments/review <draft-ietf-ops-mib-review-guidelines-00.txt> ]

On Fri, 7 Feb 2003, Wijnen, Bert (Bert) wrote:
> - sect 4.6.3 page 18
>   For table that are not read-create, but that have read-write
>   objects, I think we also want some words about persistence
>   or a StorageType object.

I have two problems with this request as it is stated:

1.) As far as I can tell from reading the DESCRIPTION clause,
it seems that the StorageType TC was not really intended to
be applied to tables that don't allow creation and deletion
of rows.  At the very least, it does not seem to be a
common practice:  a content search of the RFC database did
not turn up a single published RFC that does so.  (If I made
an error in my search, please let me know.)

In looking at the DESCRIPTION clause of the TC, and in
particular at the definitions of the enumerated values,
it also seems to me that the TC does not express what is
really wanted in the case of read-write tables, which is
whether the _values_ of the read-write columns do or do not
persist across reboots.  Here are the definitions of the
the various enumerated values:

    A row which is volatile(2) is lost upon reboot.
    A row which is either nonVolatile(3), permanent(4)
    or readOnly(5), is backed up by stable storage.
    A row which is permanent(4) can be changed but not deleted.
    A row which is readOnly(5) cannot be changed nor deleted.

The values that might apply in a table that is not
read-create are:  volatile(2), which means that the
agent will destroy the row and not recreate it after
a reboot;  permanent(4), which means that some columns
are writeable, and the row will persist (with values
intact) after a reboot;  and readOnly(5), which means
that the row cannot be written and will persist (with
values intact) after a reboot.  I would take
nonVolatile(3) to mean that the row can be deleted,
and so it would not apply.

How do I use this to say "the row persists across reboots,
but the values do not"?

It seems to me that a StorageType column is the wrong
vehicle for indicating value persistence in read-write
tables.  It's not a well-known practice (and that, after
all, is what a BCP-like document such as the guidelines
document is supposed to contain), and the semantics
don't seem to match what's wanted.

2.) Why single out read-write table objects in tables?  Why
not levy the same requirement on read-write scalars, too?

I would not object to adding a paragraph at the end of
Section 4.6.2 (which talks about DESCRIPTION and REFERENCE
clauses) that recommends specifying what happens to the value
after a reboot in the DESCRIPTION clause of a read-write object.
Here is a first cut of some possible text:

   For read-write objects (other than columns in read-create tables
   that have well-defined persistence properties) it is RECOMMENDED
   that the DESCRIPTION clause specify what happens to the value
   after an agent reboot.  Among the possibilities are that the value
   remains unchanged, that it reverts to a well-defined default value,
   or that the result is implementation-dependent.

Reactions?

Mike