Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10)

From: Minnie Lu <[email-masked]>
Date: Thu, 15 Apr 2004 17:55:42 -0700

Hi, Eduardo,

How about adding the following in the description ?
"Non-active row (rowStatus in 'notInService' or 'notReady') MAY be 
destroyed by the agent at reinitialization of the managed system to save 
the resources".

This serves a hint to the user that if they wants to persist any rows 
across CMTS reload, besides setting the StorageType to 
nonVolatile(3),  user also needs to set the rowStatus to active.

As aging non-active rows during the run time, I think it could be vendor 
dependant implementation.

Thanks a lot !
Minnie

At 04:56 PM 4/15/2004 -0600, Eduardo Cardona wrote:
>That's a good pointer,
>Thanks Randy
>I personally was not aware of this language in the lengthy RowStatus
>description, my apologize
>
>Minnie, Going back to your question, I now think the aging of
>'superfluous' entries is the behavior by default for SNMP and I should
>put myself in a non-deviating position of that. In the other hand if the
>5 minutes by default of RFC 2579 is not convenient, would you have any
>text proposal for this matter?
>
>Thanks
>
>Eduardo
>
>
>
>
>-----Original Message-----
>From: Randy Presuhn [mailto:[email-masked]]
>Sent: Thursday, April 15, 2004 2:54 PM
>To: [email-masked]
>Subject: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10)
>
>
>Hi -
>
> > From: "Eduardo Cardona" <[email-masked]>
> > To: "Minnie Lu" <[email-masked]>
>...
> > Sent: Thursday, April 15, 2004 1:04 PM
> > Subject: RE: V2 Changes for next RFI v2 MIB (draft 10)
>...
> > Specially I am not comfortable with the case of : active ->
> > notInService
> > -> reboot -> "where is my old entry"?
>...
>
>If you do NOT want it to work this way, then you'll need to put language
>to that effect into the DESCRIPTIONs for the RowStatus object. RFC 2579
>page 16 makes it clear why:
>
>             If the management station is prevented from setting the
>             status column to `active' (e.g., due to management station
>             or network failure) the conceptual row will be left in the
>             `notInService' or `notReady' state, consuming resources
>             indefinitely.  The agent must detect conceptual rows that
>             have been in either state for an abnormally long period of
>             time and remove them.  It is the responsibility of the
>             DESCRIPTION clause of the status column to indicate what an
>             abnormally long period of time would be.  This period of
>             time should be long enough to allow for human response time
>             (including `think time') between the creation of the
>             conceptual row and the setting of the status to `active'.
>             In the absence of such information in the DESCRIPTION
>             clause, it is suggested that this period be approximately 5
>             minutes in length.  This removal action applies not only to
>             newly-created rows, but also to previously active rows which
>             are set to, and left in, the notInService state for a
>             prolonged period exceeding that which is considered normal
>             for such a conceptual row.
>
>Consequently, if the WG wants the peculiar behaviour of having
>non-active rows survive re-boots, you'll need to spell it out in the
>DESCRIPTIONs.
>
>Randy
>
>
>
>_______________________________________________
>IPCDN mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ipcdn
>
>
>_______________________________________________
>IPCDN mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ipcdn

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 15 Apr 2004 20:11:57 -0700

Hi -

> From: "Minnie Lu" <[email-masked]>
> To: "Eduardo Cardona" <[email-masked]>
...
> Sent: Thursday, April 15, 2004 5:55 PM
> Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10)
...
> destroyed by the agent at reinitialization of the managed system to save

I don't see how this would help interoperability.

RFC 2119 says:
   MAY   This word, or the adjective "OPTIONAL", mean that an item is
   truly optional.  One vendor may choose to include the item because a
   particular marketplace requires it or because the vendor feels that
   it enhances the product while another vendor may omit the same item.
   An implementation which does not include a particular option MUST be
   prepared to interoperate with another implementation which does
   include the option, though perhaps with reduced functionality. In the
   same vein an implementation which does include a particular option
   MUST be prepared to interoperate with another implementation which
   does not include the option (except, of course, for the feature the
   option provides.)

As a practical matter, the proposed language still means that
management applications MUST be prepared to work with
managed devices where the non-active rows disappear on
reboot, as one would expect from the RowStatus definition.
(Neglecting the corner case of reboots completing in less than five
minutes from the creation of the row.)

> nonVolatile(3),  user also needs to set the rowStatus to active.

They would need to do this anyway, based on the definition of
StorageType and of RowStatus.

...

This doesn't seem consistent with the definition of RowStatus, unless
you add language to the object's description saying that these things
may be retained indefinitely.

Randy