Re: Question on RowStatus

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Cc: "Tom Nadeau (E-mail)" <tnadeau@cisco.com>
> Sent: Friday, May 16, 2003 6:38 AM
> Subject: Question on RowStatus
>

> In the MPLS LSR mib, I see:
>
> mplsInSegmentStorageType OBJECT-TYPE
>    SYNTAX        StorageType
>    MAX-ACCESS    read-only
>    STATUS        current
>    DESCRIPTION
>        "This variable indicates the storage type for this
>         object. If this object is set to readOnly(5), and the
>         corresponding LFIB entry is removed, then the agent
>         MUST remove this row shortly thereafter [RFC2579].
>         The agent MUST ensure that this object's value
>         remains consistent with the associated mplsXCEntry.
>         The default value is volatile(2)."
>    DEFVAL { volatile }
>    ::= { mplsInSegmentEntry 11 }
>
> 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.  :-)

> - The sentence about an agent needing to keep the object consistent
>   with one or more stoargeTypes in other tables worries me.
...

I have the same misgivings.  I'd rather it spelled out what it means
for one of these to exist when there is no corresponding LFIB entry.
(Removing the interdependencies might also simplify configuration.)

Randy