Re: Question on RowStatus

[John Flick <johnf@rose.hp.com>]

Randy Presuhn wrote:
> 
> Hi -
> 
> > From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> > To: "Randy Presuhn" <randy_presuhn@mindspring.com>; "Mreview (E-mail)" <mreview@ops.ietf.org>
> > Cc: "Tom Nadeau (E-mail)" <tnadeau@cisco.com>
> > Sent: Friday, May 16, 2003 8:45 AM
> > Subject: RE: Question on RowStatus
> >
> 
> > > > My questions:
> > > > - I think that it is OK that an agent can remove such readOnly rows
> > > >   when the underlying data ceases to exist. If anyone thinks that
> > > >   is not correct, pls holler.
> > >
> > > Uhh, they way readOnly is described in RFC 2579 ("completely in ROM")
> > > makes it sound like it should go away only if someone removed
> > > the chip. (or if setting the RowStatus to "delete" caused the chip to
> > > be ejected.  :-)
> > >
> > To be fair, it says: -- e.g. completely in ROM
> 
> The first paragraph of the TC DESCRIPTION says "backed up by stable
> storage."  My recollection from the early days of the TC is that the "e.g."
> was for purposes of storage technology neutrality.
> 
> > So that is just an example. It could be completely readOnly for other
> > reasons, no? So in this case it is readOnly because (for example) the
> > entry gets created by some labelDistribution protocol, and so the
> > implementations wants to show it but not make it changable
> > via SNMP. So then readOnly might be appropriate. If then later
> > that segment goes away (because of whatever underlying reason), then
> > it seems OK (at least to me) to indeed remove the row as well.
> ...
> 
> I think that that would be at odds with the "backed up by stable storage"
> requirement. Do they expect something created by an LDP to survive a
> reboot?  The "permanent"/"readOnly" distinction relates to whether
> it is possible to modify any of the other attributes in the row.  I can understand
> the hypothetical need, but I don't see how StorageType would meet the
> requirement.
> 
> Randy

In cases where you have a table where some rows are created by some dynamic
mechanism and are read-only to SNMP, and some rows can be configured using
SNMP, I usually prefer the approach taken for VLAN configuration in RFC 2674.
Have one table that is read-only containing all known rows, whether dynamically
learned or statically configured, and a second read-create table for configuring
the static entries.

John