[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Question on RowStatus
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