Re: Question on RowStatus

[Harrie Hazewinkel <harrie@lisanza.net>]

HI,

Not having looked at the MPLS-MIB yet, but some things I noticed.

On Friday, May 16, 2003, at 03:38 PM, Wijnen, Bert (Bert) wrote:

> 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.
'this object' I wonder if this is ment. I suggest
fixing the wording into 'this entry' if it applies to the
complete entry. Object could be ambiguous.

>  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.
I would agree.

> - The sentence about an agent needing to keep the object consistent
>   with one or more stoargeTypes in other tables worries me.
>   I guess it is OK. Maybe what I want them to do is to add text aka:
>         If a SET request tries to set a vlue that is inconsistent
>         with that associated mplsXCentry, then a inconcistentValue
>         error should be returned.
I agree on the extra text, but since the mplsXEntry is extending
this one (I presume) it would be more logical the other way around.
The mplsXEntry needs to be consistent with this one.
Also I am not sure how both 'StorageTypes' would relate, since it
looks to me that both values should always be equal. If so the
question arises is the second StorageType needed.

Hope this helps,

Harrie